X-List-Received-Date: Mon, 04 Nov 2019 10:27:05 -0000

Hi Neil and thanks for the feedback ! I will try to comment a bit inline= of your reply:

Le 29 octobre 2019 12:20, de neilj@fast= mailteam=2Ecom

Some feedback on this d= raft:

It's mail-specific at the moment, but= could probably be made pretty generic, which I think would be more useful= =2E e=2Eg=2E Instead of "mesageCount" and "mesageStorageSize" we'd just hav= e "size" or "count" as the types of quota, which could apply to any object = type=2E Then you have another property on the Quota object that lists = the data type(s) it applies to=2E

Yes I= got that comment a few times already, the document definitely needs to be= made more generic=2E

I'm a bit unclear on how = "usedScope" and "limitScope" could be different and what this would mean in= practice (and if this is actually done in the real world)=2E

Actually I'm starting to think as well this just adds extra= complexity=2E=2E=2E Only one field "scope" might be enough, and then we c= an have different quotas declared for each scope (global, domain, account,= =2E=2E=2E)=2E Will think more on this (debate is open of course)=2E
<= /p>
I'm not sure I see the purpose of the "quotaIds" pro= perty addition to the Mailbox object=2E I feel it would be cleaner not to a= dd this (but add a property to the Quota object to indicate a subscope if i= t only applies to a subset of the objects of that type in the account)=2E

I think as Benoit tried to say in his reply, we= first thought by adding the "quotasIds" to the mailbox object, it would b= e easy for the client to fetch the quota affecting the account from the ma= ilbox and show the usage to the user=2E We thought as well maybe it can be= then fine-grained to the point where you can have special quotas for spec= ific mailboxes that don't apply to the rest of the account=2E=2E=2E
<= br>But is this level of fine-grained needed? Wanted? Maybe it's overkill a= nd redundant (like you need to put the quota id to all mailboxes if it's g= eneral to the account) and we can discuss about that=2E But you are right = as well to mention the calendar, it could be linked to quotas as well, and= the mailbox is not the only object affected then=2E But linking it to wha= t then?

You can have users that have a normal quota (2Go for examp= le), premium with 5Go and VIP with unlimited=2E=2E=2E Maybe part of the Ac= count object? Or do you have a better idea?

<= /div>
Cheers,
Neil=2E

Che= ers,
Rene Cordier=2E
From nobody Mon Nov 4 12:55:31 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 A520712002E for ; Mon, 4 Nov 2019 12:55:29 -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=bluepopcorn.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 33qUM-zElXYB for ; Mon, 4 Nov 2019 12:55:28 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 4D4ED120018 for ; Mon, 4 Nov 2019 12:55:28 -0800 (PST) Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xA4KtMZM022161 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 4 Nov 2019 12:55:23 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1572900923; bh=Ex55I798fAGkMxctm4kNay4pUM+zu5jWbk6NcIazqUw=; h=To:From:Subject:Date; b=Ohg18ZLHifpptdVlS60Lww3v97BuafYHokzIS6VYaXeQc11zFFuuHkDYLALu987jd JoBefvGKVRy3aIUXg8Qq/VELng3IZjt1xt51vDnyI404lhGQCotXsQlB2HgHbA5dVW U0cSu7R1dj6qndD4mwr7xjUJimkXa9C9VOovM2W0= To: jmap@ietf.org, Ken Murchison From: Jim Fenton Message-ID: <652de948-53ba-ddb4-1c40-25df28b1c42e@bluepopcorn.net> Date: Mon, 4 Nov 2019 12:55:17 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Jmap] Comments on draft-ietf-jmap-websocket-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, 04 Nov 2019 20:55:30 -0000 A few minor comments on the websocket-03 draft, currently in WGLC: - Section 2: I'm not sure what the reference [1] is about (and correspondingly, the URIs section 8.3). I'd suggest leaving that out; it seems to be confusing the idnits tool as well. - Section 3: supportsWebSocketPush: The value is shown as "Boolean", which would lead me to perhaps believe that it would be something like "supportsWebSocketPush": "true" while the example doesn't have quotes around "true". My inclination would be to leave off the quotes around Boolean, but I'm not a JSON syntax expert by any stretch of the imagination so decide accordingly. - Sections 4.2.2 and 4.2.3: requestId is shown as optional in the response, and may only be included if there was a requestId in the request. If there is a requestId in the request, should the requestId be mandatory in the response? I think it should. - Next time you're making an update, please change the reference to jmap-mail to RFC 8621. -Jim From nobody Mon Nov 4 15:06:19 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 C4308120812 for ; Mon, 4 Nov 2019 15:06:16 -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=bluepopcorn.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 uo3yrbrPzGSJ for ; Mon, 4 Nov 2019 15:06:15 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 261AB1200FA for ; Mon, 4 Nov 2019 15:06:15 -0800 (PST) Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xA4N68D1023737 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 4 Nov 2019 15:06:09 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1572908769; bh=tKnyEfE9mXIG3yBmq95mhCtQVxYZi5s9tZX2YftK9nw=; h=To:From:Subject:Date; b=LpOQIs8demohhCXmLmzFfbKRJDDclbF+ENCi3JSh3t0yKrpPNfn5okVFw/DrSJG5g fZxe1r9QpeAwjEE5tzXmVvvu6yLNd7nEGgEBbmyE2ayDxO8X6xKjt7GQKpS5mnMwuS qphHYGtVsfYd2Yfu4Cx81iUsk8EqwFlPsQ+WBdQY= To: jmap@ietf.org, Ken Murchison From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: Date: Mon, 4 Nov 2019 15:06:03 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: [Jmap] WebSocket Push question 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, 04 Nov 2019 23:06:17 -0000 In Section 4.3 of the draft, after establishing the WebSocket connection, the client does a WebSocketPushEnable with a pushState of aaa. Where did this initial state come from, a previous session perhaps? If not, I wonder if the pushState parameter should have been left off. Presuming this is from a revious session, I'm wondering how the server manages the pushStates. Does it need to keep an archive of all of the pushStates it has used, so that multiple clients can establish a WebSocket connection and resume from where they left off? Or is there some per-client tag that it can use to maintain only one pushState per client? -Jim From nobody Tue Nov 5 06:49:51 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 D152712084D for ; Tue, 5 Nov 2019 06:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=kcGTb+4R; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QaueOCP0 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 oyf3ei79AacJ for ; Tue, 5 Nov 2019 06:49:46 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF7B1208FF for ; Tue, 5 Nov 2019 06:37:42 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id EE591459; Tue, 5 Nov 2019 09:37:41 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 05 Nov 2019 09:37:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=fm1; bh=ekS8V+xkEa8uIB3tNt0PQhDaLW FM6Z/HnWdgAyBKpLk=; b=kcGTb+4RSoQjSOxqLpaiMaawwHGZMnyiMTPsp8NBSg SejO0MMdHLRfJQF1R12HaxEiRlxM9AKVHijNDC3AdvucJkRVPvjv6EELUi3rOGV6 6Vgj6sda/iKwhV4k1q+FwhlisOEbc4l5deqXAlDl+dw8MJPZWNfnfV2RbFhFdh9/ BOps3E8EzJJBSanMv6ipBRP1znu2EVfSCAxHhlWJHsvQC/EY07IuslXv11DuebFc ifir6rSwb7faCFA7XPsSpVaxptCj00wQn79WFcAtFBsXZVMrLHjMKD2lbfEoOvXt eRwkG4QeIKTfbgdNteGegrJbyoS1I9CT2IToZgLXLLfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ekS8V+xkEa8uIB3tNt0PQhDaLWFM6Z/HnWdgAyBKp Lk=; b=QaueOCP04zJTy+0LTAPZ7LWV4TRtSzS2h8j12307qUHB/vDFtGPLxY295 lybez70rxYaOic2RovJxR44plVOzhndSmGFcLPar6SWx7cCC8jmK6aeiBm0swItX 2WAZe7AVAAbY5Bn+tuWCVzUTtJRaNvkVW3N6qz5C4+jALNnwdi/rmbzbxHa8bF6W tgVHl5TyPpz//Fli5qyXCoNZQjFNov7CHpU9JoNzUF6gc+jvpvb8zYXNBjy6N+YE Jka+ql420/iA2ZRMtJL6GuNEp7Uqwrzwn4Kv1Ke33X4j/7CDMJcrc39BwrGrRBfd XYjZr3ZdTQSDXb6rbYMVZs3BeU/Rg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduhedgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefmvghn ucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucfkphepjeegrdejjedrkeehrddvhedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm uhhrtghhsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id EB408306005C; Tue, 5 Nov 2019 09:37:40 -0500 (EST) To: Jim Fenton , jmap@ietf.org References: From: Ken Murchison Organization: FastMail US LLC Message-ID: <6039a470-edcd-dd3d-1afb-5ef137eb8993@fastmailteam.com> Date: Tue, 5 Nov 2019 09:37:40 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] WebSocket Push question 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: Tue, 05 Nov 2019 14:49:49 -0000 On 11/4/19 6:06 PM, Jim Fenton wrote: > In Section 4.3 of the draft, after establishing the WebSocket > connection, the client does a WebSocketPushEnable with a pushState of > aaa. Where did this initial state come from, a previous session perhaps? > If not, I wonder if the pushState parameter should have been left off. > > Presuming this is from a revious session, I'm wondering how the server > manages the pushStates. Does it need to keep an archive of all of the > pushStates it has used, so that multiple clients can establish a > WebSocket connection and resume from where they left off? Or is there > some per-client tag that it can use to maintain only one pushState per > client? Yes, "aaa" is from a previous session. pushState is an opaque token so that the server can implement it in any way that it chooses. But in the case if the Cyrus JMAP server, we leverage IMAP modification sequence numbers on a per-account basis. Each change to data or meta-data bumps the current highest modseq and associates this new modseq with the changes. When a client requests changes since a given modseq (pushState) we simply find all changes with a higher modseq than the one provided. -- Ken Murchison Cyrus Development Team FastMail US LLC From nobody Tue Nov 5 06:53:30 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 A00F2120C1D for ; Tue, 5 Nov 2019 06:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=pmqmF7e8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hhv2Yor0 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 qgkLbhn6SlB4 for ; Tue, 5 Nov 2019 06:51:32 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0941208CB for ; Tue, 5 Nov 2019 06:36:31 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 8DD3A4A3; Tue, 5 Nov 2019 09:29:33 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 05 Nov 2019 09:29:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=fm1; bh=zkHgb37TlpMB9Wr6JGlqDnNgku tqSCJtzHlDIOrSK4E=; b=pmqmF7e88NpXTf+yyahE08RkwYP+5jr1m9se+3Cwoy 9Bom2YtXL6/5sGn99sho4eUt8o70Og5KlNQZhgF+lCVVDZNqok2+Cp/j4Rdu1ztZ dlwCWDQPXmThw0hwgz/XQRLMfDBJxWt+EHB+80FIud1CkRB/itUSiIC1zo0EMlbs TIoV71T8c4KztHSqRB+QCccmDhYJAvtX9LLy03zdL1uw7i2PCdiJG07FenFiAQon OY3uRcL6lrT2CgfNafgjEBbl7Inhdz7m9WpcYUCUm2NeQRl/4HrgABSPSC9d+Q9+ NprydOxgX+CQoaNllqaZGufyklt3rFgYEny701N3DjsQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=zkHgb37TlpMB9Wr6JGlqDnNgkutqSCJtzHlDIOrSK 4E=; b=hhv2Yor0RmoG5g3U5QypIj3yVHt++DZH2JoKKmzcWHc4Ve5H3P3zLGPwd if43y9L35u3aw9q1/Ay4Vsg96iXCgJfL75rZWtefmdrTsmH3TY7RAuhw//XjbS3R ENaelAVmQyIgxF924nqNvEeolvjNIdLFJtYWSsx7btmBET91GuSAT4fkYFmOQGDS il2NuobeHL9YPx+vniiDT7bkwtVhzFy7jOe+Yji/l230ngPq9OTWPPcCi+YmHfYP FsuCO+n2lSmRGLBY0aWhRQwA8A4gTthHFXsHbmGEaWvzOpPUCEiozD91ANNVC7Ug yGV0AhofnpzZNiAJCNsFxw//gKbdw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduhedgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefmvghn ucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucfkphepjeegrdejjedrkeehrddvhedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm uhhrtghhsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 7C6073060061; Tue, 5 Nov 2019 09:29:32 -0500 (EST) To: Jim Fenton , jmap@ietf.org References: <652de948-53ba-ddb4-1c40-25df28b1c42e@bluepopcorn.net> From: Ken Murchison Organization: FastMail US LLC Message-ID: <1bb16b08-7c04-2ac0-334a-3fe95db1bb3c@fastmailteam.com> Date: Tue, 5 Nov 2019 09:29:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <652de948-53ba-ddb4-1c40-25df28b1c42e@bluepopcorn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] Comments on draft-ietf-jmap-websocket-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: Tue, 05 Nov 2019 14:51:40 -0000 Hi Jim, Thanks for the review. Responses inline. On 11/4/19 3:55 PM, Jim Fenton wrote: > A few minor comments on the websocket-03 draft, currently in WGLC: > > - Section 2: I'm not sure what the reference [1] is about (and > correspondingly, the URIs section 8.3). I'd suggest leaving that out; > it seems to be confusing the idnits tool as well. That was a function of using an for BCP 14. I've removed that and just used plaintext instead. > > - Section 3: supportsWebSocketPush: The value is shown as "Boolean", > which would lead me to perhaps believe that it would be something like > "supportsWebSocketPush": "true" while the example doesn't have quotes > around "true". My inclination would be to leave off the quotes around > Boolean, but I'm not a JSON syntax expert by any stretch of the > imagination so decide accordingly. I'm no JSON syntax expert either, but the use here is consistent with RFCs 8620 and 8621, so I think I'll keep it as-is. > > - Sections 4.2.2 and 4.2.3: requestId is shown as optional in the > response, and may only be included if there was a requestId in the > request. If there is a requestId in the request, should the requestId > be mandatory in the response? I think it should. I agree. I've changed this to be "(optional; MUST be returned if given in the request)" > > - Next time you're making an update, please change the reference to > jmap-mail to RFC 8621. Done. -- Ken Murchison Cyrus Development Team FastMail US LLC From nobody Sun Nov 17 05:14:42 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 0C1591200CD; Sun, 17 Nov 2019 05:14: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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <157399647499.20900.15107026287568104192@ietfa.amsl.com> Date: Sun, 17 Nov 2019 05:14:35 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-websocket-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: Sun, 17 Nov 2019 13:14: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 : A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket Author : Kenneth Murchison Filename : draft-ietf-jmap-websocket-04.txt Pages : 14 Date : 2019-11-17 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 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-websocket-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-websocket-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 Tue Nov 19 22:58:22 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 555A5120818 for ; Tue, 19 Nov 2019 22:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=K8v+sXWb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uNDSK9jT 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 Uu-ZoAzkpQ1y for ; Tue, 19 Nov 2019 22:58:18 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93898120801 for ; Tue, 19 Nov 2019 22:58:18 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 1EE53567 for ; Wed, 20 Nov 2019 01:58:18 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 20 Nov 2019 01:58:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm1; bh=gV9DO1n/o1wun1iEshz5NsbopHRKO6K6EtjPLmX +Ye0=; b=K8v+sXWbThawQig5cHEgr3Z3M5L98bkjmjPeQk0lKB6XJnxpc1e2Nd4 nBBuhGguffQWdzZLfPfEwS8wYz/p6Wi5iCwD/NEe9SfmjKkgvA8i9oS+fKQs+zNn L2D0FfOhVXMbKDp7/mJFBCz5wQv6Pso8F1jWA234VqLTM6jP6Puv1E5cyRrN6VCp rXq4+Mj3VDl488tn0X6OlGuPSQc+uVOddw0vZ+3cXNR6BMR0aiMif3AGK7xl8n4f NHfQQE3b7CsDY3TbDvZXvcOytk4CDQX0xwQlaCFEI+M4NSdHwhpkbR4D5P3r6//y Axh+FMSGkAWnz+k8EX15G91uGXfrVaQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=gV9DO1n/o1wun1iEshz5NsbopHRKO 6K6EtjPLmX+Ye0=; b=uNDSK9jT3DumkTvYkqxjppmngR/KgbHqxHSPqsGsPuFHv HGZB0IoLhhYmsljq63f7ysnnaNQOulTCNGdLWuxpp2C8RtN72LC3CMkuaRyohiRa s4kPDZbQRwnpOG/HwMoQhF7kHv9Vqg/UFK1zj378eRqrzuFwHnafRd6ZsNNjODw9 BNiO4NRnOZvhP8eMGDuH4BnAfXQO/g1x5uOqRiSTsCyUMldSaFIfNnrWBIu1TtRO qYsUXQeaC4ma8LZA8rCMkF3NCS5OMIVVGJ+gbIXk5IbztF911puFZsvGuTErBWCs 4weTYwCOW9MA3yCcnQIO5EPBc+XhVhvb5UjsdPQTQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudegledguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrh honhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3A30930006F; Wed, 20 Nov 2019 01:58:17 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <9d2bfd74-f109-4c40-8608-795346cb93ce@dogfood.fastmail.com> Date: Wed, 20 Nov 2019 17:58:14 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=6e7e57d042814029996bcfe8130d59aa Archived-At: Subject: [Jmap] Minutes uploaded 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, 20 Nov 2019 06:58:21 -0000 --6e7e57d042814029996bcfe8130d59aa Content-Type: text/plain Hi all, I've uploaded the minutes to the datatracker, and I will paste them below here. There are action items for three of us, as well as a "lessons learned" to myself to make sure that authors who were possibly going to attend remotely are checked with close to the meeting date so we know who to expect - because we were missing information for many of the documents! Cheers, Bron. IETF106 JMAP WORKING GROUP - Singapore 2019-11-19, 17:10-18:40 = AGENDA Intro, Note Well and Agenda: 5 min Current Drafts: - calendars: 30m - mdn: 10m - quotas: 10m - smime: 5m Proposed new work: - JSContact: 20m Other business: - More general push support? 5m - Milestone review: 5m = ACTIONS Bron: * follow up with authors and issue WGLC for MDN * kick off discussion on the list again and follow up with authors for QUOTA * prod authors to keep researching and updating text for JSContact * write up something with all the known drafts and look for potential author for a combined draft for PUSH * update WG milestones Jim: * submit JMAP over Websocket document to IESG for publication Neil: * issue revised draft for JMAP Calendars * collect implementation experience for JMAP Calendars = DETAILED NOTES == websocket Jim briefly mentioned that Ken has uploaded a revision to the draft which addresses the issues raised during last call, and he will now submit it for publication. ACTION: Jim to submit jmap over websocket document to IESG for publication == calendars Neil: * planning to add many more examples to the draft * examples are particularly useful for implemention, though the prose needs to cover detail too * current draft is based on review at the interim meeting a CalConnect in October * expect the next step to be gaining implementation experience * CalendarEventNotification and ShareNotification in different places for good reasons * Share needs to exist before/after access to accounts * Event Notification has to be per-user and stored in the account Specific items: * mayAddParticipants ACL? Not in CalDAV so we won't add it to jmap-calendars, adds complexity for unclear value * access to original name/colour? - Barry: mostly you won't care - Seph: maybe useful, but can't see a specific case - nobody else could a use case either - Bron: easy to add later in an extension if we find a need * Sharees act as -> wording change. Neil will do. * hideGuestList and allowForwarding - Bron: should it be in jscalendar instead? - Neil: it's only related to the jmap-calendars stuff here, we'll add it to the registry - Bron: good, will show registry use and make it not stale - delegation is in icalendar, but rarely used - likewise party crashing, but there's no formal method to say what the server will allow - likewise "take over", we should define it clearly in JMAP/jscalendar - counter proposals are in icalendar, but unused - we really want VPOLL / jspoll * maxSizeCalendarEvent - so long as there's a clear error code for itemTooBig, there's no point publishing the limit - can always add in an extension later! * Alerts using "psuedo-type", like with Mail for "new messages only" - but it's not a state change - nobody had a problem with this Implementations: * mostly interested in server first, but definitely be good to have many clients too! * ideally do interop testing at CalConnect and IETF Hackathons ACTION: Neil to issue revised draft, then implementations == mdn The author wasn't present, and nobody remembers anything since last time, where we said "basically ready". ACTION: Bron to follow up with authors and issue WGLC == quota Authors were not present, but we had some opinions in the room! Neil: * the separate scoping is weird and hard to present in a client Bron: * it doesn't specify quota setting, only "get" and "changes" * Alexey and Neil agree that it's probably OK to be only get, at least this draft - often quotas are managed out of band anyway Alexey: * We should share the registry which the EXTRA quota draft creates ACTION: Bron to kick off discussion on the list again and follow up with authors == smime Alexey: * should have time to work on this again soon * split into 2 docs, one for verify only and one for more complex server side key management and signing Bron: * so - make this the simple doc, get it done early next year, adopt the other one next year too Alexey: * sounds good! == jscontact Neither of the authors were present. Neil: * in some ways this is much simpler than calendars - no timezones, recurrences, etc * but - real people! Names and Addresses are complex * we think we have a neat solution - list of items with tags Barry: * is all this in the draft? Would have to see text and examples to see if it's good * would we have a registry of known tags? Neil: * yes, initial registry in document and ability to add new * registry may need to specify use of tags for sorting and other properties on them Bron: * do we need a way to tag name part items as "do not include in display"? Alexey: * doesn't look too horrible by this description - some discussion of LDAP and how this is more powerful * need to seek people with experience in other fields / other parts of the world for how they use names Barry: * Spanish names for example, there can be a lot of names and the "Surname" for sorting is somewhere in the middle Neil: * related - we need to handle alternative names (Stage name, Pen name, Formal name, etc) which is not the same as additional name parts * don't want to wind up with an array of arrays! complexity vs usability Jim: * we'll need to represent pronouns too Pete: * Apple does Name/Nick Name/Phonetic Name - even with just that, clients often get it wrong! * let's not get too far into the weeds with complexity Bron: * everybody loves this bikeshed! We know enough to have opinions... Barry: * let's wait for text and review it then Neil: * good news, the format will be the hard part here! JMAP Addressbooks should be very easy once the format is defined Bron: * people in CalConnect are also involve with ISO, and ISO are also working on formats for names and addresses, we will keep working with them! * NOTE: recharter is not yet through, so we won't adopt this document until the charter is adopted ACTION: Bron - prod authors to keep researching and updating text == Push Bron: * Push stuff was proposed in DISPATCH, and Alexey suggested maybe JMAP is the right home due to JMAP already having done the hard work on PUSH. * do we need to recharter AGAIN? * DISPATCH also mentioned RFC8599 - which is the same thing for SIP! Alexey: * please write up all the drafts and detail * maybe HTTPBIS will be interested if there's a draft that fits their charter ACTION: Bron to write up something with all the known drafts and look for potential author for a combined draft == Milestones JMAP mail RFC5322 translation guide document: * Barry : set it to 2099? * Alexy: NO! * Bron: will make it Dec 2020 and review then for drop if still no movement Websockets to IESG: Nov 2019 (now!) Calendars to IESG: Nov 2020 (need implementation experience) MDN to IESG: Dec 2019 (nearly done) Quota to IESG: Feb 2020 (still work to do) smime basic to IESG: Feb 2020 Adopt smime full: Feb 2020 Adopt JSContact: Jan 2020 (once charter lands) JSContact to IESG: Dec 2020 Adopt Contacts for JMAP spec: July 2020 ACTION: Bron to update milestones == Other business No other business Due to lack of authors being present, we only used 60 of our 90 minutes, but we think we did ask for the right amount of time. LESSON LEARNED: Bron to follow up with authors who might be attending remotely close to the event, to check if they're still able to join rather than assuming they will! -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --6e7e57d042814029996bcfe8130d59aa Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all,

I'v= e uploaded the minutes to the datatracker, and I will paste them below h= ere. There are action items for three of us, as well as a "lessons= learned" to myself to make sure that authors who were possibly going to= attend remotely are checked with close to the meeting date so we know w= ho to expect - because we were missing information for many of the docum= ents!

Cheers,
=
Bron.

IETF106 JMAP WORKING GROUP - Singapore 2019-11-19, = 17:10-18:40

=3D AGENDA

Intro, Note Well an= d Agenda: 5 min
Current Draft= s:
- calendars: 30m
=
- mdn: 10m
- quotas: 10m
- smime: 5m
Proposed new wor= k:
- JSContact: 20m
=
Other business:
- More general push support? 5m
- Milestone review: 5m

=3D ACTION= S

Bron:
* foll= ow up with authors and issue WGLC for MDN
* kick off discussion on the list again and follow up with = authors for QUOTA
* prod auth= ors to keep researching and updating text for JSContact
* write up something with all the known draft= s and look for potential author for a combined draft for PUSH
<= div style=3D"font-family:Arial;">* update WG milestones

J= im:
* submit JMAP over Websoc= ket document to IESG for publication

Neil:
* issue revised draft for JMAP Calendars
* collect implementation experi= ence for JMAP Calendars

<= /div>
=3D DETAILED NOTES

=3D=3D websocket

<= div style=3D"font-family:Arial;">Jim briefly mentioned that Ken has uplo= aded a revision to the draft which addresses the issues raised during la= st call, and he will now submit it for publication.

ACTION:= Jim to submit jmap over websocket document to IESG for publication
<= /div>

=3D=3D calendars
<= br>
Neil:
* planning to add many more examples to the draft
* examples are particularly use= ful for implemention, though the prose needs to cover detail too
* current draft is based on review a= t the interim meeting a CalConnect in October
* expect the next step to be gaining implementation exp= erience
* CalendarEventNotifi= cation and ShareNotification in different places for good reasons
* Share needs to exist before/after= access to accounts
* Event N= otification has to be per-user and stored in the account

= Specific items:
* mayAddParti= cipants ACL? Not in CalDAV so we won't add it to jmap-calendars, a= dds complexity for unclear value
* access to original name/colour?
- Barry: mostly you won't care
- Seph: maybe useful, but can't see a specific case
=
- nobody else could a use case either<= br>
- Bron: easy to add later in = an extension if we find a need
* Sharees act as -> wording change. Neil will do.
* hideGuestList and allowForwarding
<= /div>
- Bron: should it be in jscalenda= r instead?
- Neil: it's only = related to the jmap-calendars stuff here, we'll add it to the registry
- Bron: good, will show regist= ry use and make it not stale
= - delegation is in icalendar, but rarely used
- likewise party crashing, but there's no formal method= to say what the server will allow
- likewise "take over", we should define it clearly in JMAP/jscale= ndar
- counter proposals are = in icalendar, but unused - we really want VPOLL / jspoll
* maxSizeCalendarEvent
- so long as there's a clear error code for itemToo= Big, there's no point publishing the limit
- can always add in an extension later!
* Alerts using "psuedo-type", like with Mail fo= r "new messages only" - but it's not a state change
- nobody had a problem with this

Imp= lementations:
* mostly intere= sted in server first, but definitely be good to have many clients too!
* ideally do interop testing a= t CalConnect and IETF Hackathons

ACTION: Neil to issue re= vised draft, then implementations

=3D=3D mdn

The author wasn't present, and nobody remembers anything since last t= ime, where we said "basically ready".

ACTION: Bron to fol= low up with authors and issue WGLC

=3D=3D quota
=

Authors were not present, but we had some opinions in the room!

Neil:
* the sepa= rate scoping is weird and hard to present in a client

Bro= n:
* it doesn't specify quota= setting, only "get" and "changes"
* Alexey and Neil agree that it's probably OK to be only get, at l= east this draft - often quotas are managed out of band anyway
<= div style=3D"font-family:Arial;">
Alexey:
* We should shar= e the registry which the EXTRA quota draft creates

ACTION:= Bron to kick off discussion on the list again and follow up with author= s

=3D=3D smime

Alexey:
* should have time to work on this again soon
* split into 2 docs, one for ve= rify only and one for more complex server side key management and signin= g

Bron:
* so -= make this the simple doc, get it done early next year, adopt the other = one next year too

<= div style=3D"font-family:Arial;">Alexey:
* sounds good!
=3D=3D jscontact

Neither of the authors were present.

Neil:
* in some ways this is much simpler than = calendars - no timezones, recurrences, etc
* but - real people! Names and Addresses are complex=
* we think we have a neat so= lution - list of items with tags

Barry:
* is all this in the draft? Would have to see = text and examples to see if it's good
* would we have a registry of known tags?

Neil:
* yes, initial registry in doc= ument and ability to add new
= * registry may need to specify use of tags for sorting and other propert= ies on them

Bron:
* do we need a way to tag name part items as "do not include in disp= lay"?

Alexey:
= * doesn't look too horrible by this description - some discussion of LDA= P and how this is more powerful
* need to seek people with experience in other fields / other parts o= f the world for how they use names

Barry:
* Spanish names for example, there can be a = lot of names and the "Surname" for sorting is somewhere in the middle

Neil:
* related = - we need to handle alternative names (Stage name, Pen name, Formal name= , etc) which is not the same as additional name parts
* don't want to wind up with an array of arrays= ! complexity vs usability

Jim:
* we'll need to represent pronouns too

Pete:
* Apple does Name/Ni= ck Name/Phonetic Name - even with just that, clients often get it wrong!=
* let's not get too far into= the weeds with complexity
Bron:
* everybody loves this bikeshed! We know enough= to have opinions...

Barry:
* let's wait for text and review it then

Ne= il:
* good news, the format w= ill be the hard part here! JMAP Addressbooks should be very easy o= nce the format is defined
Bron:
* people in CalConnect are also involve with ISO, and = ISO are also working on formats for names and addresses, we will keep wo= rking with them!
* NOTE: rech= arter is not yet through, so we won't adopt this document until the char= ter is adopted

ACTION: Bron - prod authors to keep resear= ching and updating text

<= /div>
=3D=3D Push

Bron:
* Push stuff was proposed in D= ISPATCH, and Alexey suggested maybe JMAP is the right home due to JMAP a= lready having done the hard work on PUSH.
* do we need to recharter AGAIN?
* DISPATCH also mentioned RFC8599 - which is the same t= hing for SIP!

Alexey:
* please write up all the drafts and detail
* maybe HTTPBIS will be interested if there's a dra= ft that fits their charter
ACTION: Bron to write up somet= hing with all the known drafts and look for potential author for a combi= ned draft

=3D=3D Milestones

JMAP mail RFC5= 322 translation guide document:
* Barry : set it to 2099?
= * Alexy: NO!
* Bron: will mak= e it Dec 2020 and review then for drop if still no movement
Websockets to IESG: Nov 2019 (now!)
Calendars to IESG: Nov 2020 (need = implementation experience)
MD= N to IESG: Dec 2019 (nearly done)
Quota to IESG: Feb 2020 (still work to do)
smime basic to IESG: Feb 2020
Adopt smime full: Feb 2020
Adopt JSContact: Jan 2020 (once charter lands)
JSContact to IESG: Dec 2020
Adopt Contacts for JMAP spec: July 20= 20

ACTION: Bron to update milestones

=3D=3D = Other business

No other business

Due to la= ck of authors being present, we only used 60 of our 90 minutes, but we t= hink we did ask for the right amount of time.

LESSON LEAR= NED: Bron to follow up with authors who might be attending remotely clos= e to the event, to check if they're still able to join rather than assum= ing they will!

--
Bron Gondwa= na, CEO, Fastmail Pty Ltd
brong= @fastmailteam.com

--6e7e57d042814029996bcfe8130d59aa-- From nobody Tue Nov 19 23:05:45 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 03E1E120823 for ; Tue, 19 Nov 2019 23:05:32 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157423353201.5401.15208219311670277064.idtracker@ietfa.amsl.com> Date: Tue, 19 Nov 2019 23:05:32 -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: Wed, 20 Nov 2019 07:05:33 -0000 Changed milestone "Submit JMAP over websockets document to the IESG", set due date to November 2019 from September 2019, added draft-ietf-jmap-websocket to milestone. Changed milestone "Submit Message Disposition Notification document to the IESG", set due date to December 2019 from September 2019. Changed milestone "Submit document with guidance for implementation of IMAP servers and proxies (Informational)", set due date to December 2020 from December 2019. URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Wed Nov 20 00:13:18 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 1F9B4120A45 for ; Wed, 20 Nov 2019 00:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=wpJIw4Xp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=w8PXH2iz 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 XdssZg_01xkt for ; Wed, 20 Nov 2019 00:13:14 -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 A2085120896 for ; Wed, 20 Nov 2019 00:13:14 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id DE0DD54B; Wed, 20 Nov 2019 03:13:13 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 20 Nov 2019 03:13:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:cc :subject:content-type; s=fm1; bh=c5Q6DRLjhDXrvoZhChxhVO0Q/zCmZ/1 55M8xP+vhDAo=; b=wpJIw4Xp0C+FxrWExYrcrtKznJg+Tdy5CcikGK+zT7ncC8w 8TGlkZ3jlaG/Am3d3gSUjDn93UXmeLSF4ZXrx9owd5GyQyipJETbesIrY2NRDldJ rS7ZtSN/fw4DP9KOwzYKBl5/mSEoX/B6hSAjIbIrwnEMsko+K9azMutTXHAOe2Km F2LrPo6XC0LRJ7ge/ND8i66+sppldyGNE4U78Wme1gNfQCje2vh4DoKQ+ux6ninn pO/JppBAiu1cMMKRV1McXS5HIMdwf7aBfv8U0G0NJZtXQDHvYaMVFoH7TqeG+CR6 e/wrTSwYZjRre8LsrVH7Xw8vXSWZ4wxj3Q7INww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=c5Q6DRLjhDXrvoZhChxhVO0Q/zCmZ /155M8xP+vhDAo=; b=w8PXH2izzW7CWT8omIU0MeEg/Ah8J1zbVBzGfDdP/mexZ aG0304UJ+gj+iH3rqisoNdA+RAglJoPWFMOuW2OwMzoN4osgDWuPJNmj5NWuVyiF bucncHKTMW0SltvnuQfq2QAZiNELGBUnH3KnTkpypXEJod2wQLoekz045R88VhOW QQHpPGx+3WM/V/b2Zqm5bteTMsp1CrcVYYhauGrZqQLnbAEJPu0mPTpv+hxmKQNb 3oX9/+KVmcRQFXH50aeGc/QRQyiUHcvurSbufIJscHomsobTo3I/7jvMaAoNGyz/ ofvJPEKjboTkhXfY0pWPOEn3+DCsoiGL5Ta9hcq9w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudegledguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghm rdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D04FC30006F; Wed, 20 Nov 2019 03:13:12 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <4b5ccf06-1056-44e6-9192-ec88f6d092b7@dogfood.fastmail.com> Date: Wed, 20 Nov 2019 19:13:10 +1100 From: "Bron Gondwana" To: jmap@ietf.org Cc: "Raphael OUAZANA" Content-Type: multipart/alternative; boundary=794eda8c4da147f984a6a3b3a9415656 Archived-At: Subject: [Jmap] MDN: is it ready for last call 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, 20 Nov 2019 08:13:16 -0000 --794eda8c4da147f984a6a3b3a9415656 Content-Type: text/plain Hi Raphael, Sorry - I dropped the ball on MDN. It looks from the Montreal notes like it's ready for working group last call. Are you aware of any outstanding issues or questions? If so - let's get another draft out. If not, let's get to last call soon! I said on the milestones doc that we expect to send to IESG during December, so I'd appreciate getting it to last call quickly. Thanks, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --794eda8c4da147f984a6a3b3a9415656 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Raphael,
Sorry - I dropped the ball on MDN. It looks from the Montreal not= es like it's ready for working group last call. Are you aware of a= ny outstanding issues or questions?

If so - let's get another= draft out. If not, let's get to last call soon!

I = said on the milestones doc that we expect to send to IESG during Decembe= r, so I'd appreciate getting it to last call quickly.

Thanks,

Bron.

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

--794eda8c4da147f984a6a3b3a9415656-- From nobody Wed Nov 20 00:16:55 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 A727812099E for ; Wed, 20 Nov 2019 00:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=C2FaMcwW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vDUYafzM 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 LlRf8UiIirov for ; Wed, 20 Nov 2019 00:16:53 -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 8511A120AA9 for ; Wed, 20 Nov 2019 00:16:53 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id EE7812D3; Wed, 20 Nov 2019 03:16:52 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 20 Nov 2019 03:16:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:cc :subject:content-type; s=fm1; bh=128KF6PuT253u+rkx3TZpE1Rs1viyNl uT5CFz3qi7wQ=; b=C2FaMcwWzygRrg2dguEiJzK0T60khdAvlwyCI5eAce67Ybo cwxYSRcZ4dFuqZr2YMzWa30uPSPmgFzCKIw+wKzU0SLgdBa/O1uJuoYYh9dZuKmJ 6xGleQuseX6j6xbz1l4Qt5sq5kTFNixH827vvObUIPbDdn3i6ng1k4zTKxaIYnwZ ol0rxLWltXjavzr/wt60Ddumj9t0NLoeyrmWph5ToYQFLUWBzeBzeGifRICiLuZz y2kHIyPspaXRbRii7gwrJpMXx4hLjAlJGguHbjuLDSKHhsmI9BHg/raZIWYZSMQY ktk0HXSSQfCT8ExYAvhncLDSZZ75rPKaPyIV6nA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=128KF6PuT253u+rkx3TZpE1Rs1viy NluT5CFz3qi7wQ=; b=vDUYafzMhQH4xa1lvKQrAWcLYpxB84RZqmUG3+5DbWrts p+gCPE7OvnLqQBqGPJrFDW4n4aREte0KP3nzLtx6j0Mwy9mFGw60HYwVb113PlSR yP4gozyXYuf21sy7Yvd+eR4LBdYD+Jho8m2/cSNSVdq3vSopBX4iNNxEVUVkrCl/ 1BqWPjAfr84Xf4UU0E0YgboPdOui3rzMW78mF7U4OqpljiJ36yv84n3YGf/4YUph NBby7/6c6toZGL3UWSEaMl0Fej8IntXPfEn8lG4UNYra1CvhfFcQAp1x/bfwgIi2 L3HKO78M/NrQrkjoKBsXBktcij1+sLiXgu2e9p6LQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudegledguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghm rdgtohhmnecuvehluhhsthgvrhfuihiivgepud X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0BFC330006F; Wed, 20 Nov 2019 03:16:52 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <47615a98-80f2-42bd-b924-fa2721514480@dogfood.fastmail.com> Date: Wed, 20 Nov 2019 19:16:48 +1100 From: "Bron Gondwana" To: "Mario Loffredo" , "Robert Stepanek" Cc: jmap@ietf.org Content-Type: multipart/alternative; boundary=d8abe9a60a5f4cf2ac04b6c359f8d951 Archived-At: Subject: [Jmap] JSContact feedback from IETF106 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, 20 Nov 2019 08:16:54 -0000 --d8abe9a60a5f4cf2ac04b6c359f8d951 Content-Type: text/plain Hi Mario and Robert, The feedback from Singapore was largely "let's figure out what we're planning to do with names and addresses and then discuss specific text". How would you best like to manage the discussion on each of those topics? I'm happy to create Github issues, or we can do some example text on the mailing list. Unfortunately the recharter isn't quite complete yet, so I haven't accepted the draft into the working group, but once the charter comes through I will ask you upload a new version of the draft as draft-ietf-jmap-jscontact. Cheers, Born. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --d8abe9a60a5f4cf2ac04b6c359f8d951 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Mario and Robert,

The feedback from Sing= apore was largely "let's figure out what we're planning to do with names= and addresses and then discuss specific text".

How would= you best like to manage the discussion on each of those topics? I= 'm happy to create Github issues, or we can do some example text on the = mailing list.

Unfortunately the recharter isn't quite com= plete yet, so I haven't accepted the draft into the working group, but o= nce the charter comes through I will ask you upload a new version of the= draft as draft-ietf-jmap-jscontact.

Cheers,

Born.

-= -
Bron Gondwana, CEO, Fastmail = Pty Ltd
brong@fastmailteam.com<= br>

--d8abe9a60a5f4cf2ac04b6c359f8d951-- From nobody Wed Nov 20 00:51:29 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 817B91208B9 for ; Wed, 20 Nov 2019 00:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roNjYjzEN48G for ; Wed, 20 Nov 2019 00:51:26 -0800 (PST) Received: from smtp.iit.cnr.it (mx3.iit.cnr.it [146.48.98.150]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07071208C0 for ; Wed, 20 Nov 2019 00:51:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 3A41E600101; Wed, 20 Nov 2019 09:51:22 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mx3.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx3.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3a3BJ2ga4m48; Wed, 20 Nov 2019 09:51:19 +0100 (CET) Received: from [192.12.193.108] (pc-loffredo.nic.it [192.12.193.108]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id 5CA7060017B; Wed, 20 Nov 2019 09:51:19 +0100 (CET) To: Bron Gondwana , Robert Stepanek Cc: jmap@ietf.org References: <47615a98-80f2-42bd-b924-fa2721514480@dogfood.fastmail.com> From: Mario Loffredo Message-ID: <7c23212e-8eb0-8d86-7f60-f679a51ceefa@iit.cnr.it> Date: Wed, 20 Nov 2019 09:49:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <47615a98-80f2-42bd-b924-fa2721514480@dogfood.fastmail.com> Content-Type: multipart/alternative; boundary="------------CFC38EB6A0DD2811B47BA6FF" Content-Language: it Archived-At: Subject: Re: [Jmap] JSContact feedback from IETF106 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, 20 Nov 2019 08:51:29 -0000 This is a multi-part message in MIME format. --------------CFC38EB6A0DD2811B47BA6FF Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 8bit Hi Bron, I apologize for having missed yesterday's presentation at JMAP but I arrived in Singapore late in the evening. Due to some problems with my family, I couldn't book a flight to arrive earlier. In addition to that, I seriously risked to stay in Italy because of the alert about a possible Arno's flood in Pisa. I sincerely hope next presentation at JMAP is under better circustamces :-)) Il 20/11/2019 09:16, Bron Gondwana ha scritto: > Hi Mario and Robert, > > The feedback from Singapore was largely "let's figure out what we're > planning to do with names and addresses and then discuss specific text". > > How would you best like to manage the discussion on each of those > topics?� I'm happy to create Github issues, or we can do some example > text on the mailing list. > I personally prefer to work on GitHub issues. They would allow us to link the issues once fixed to the release of a draft version. > Unfortunately the recharter isn't quite complete yet, so I haven't > accepted the draft into the working group, but once the charter comes > through I will ask you upload a new version of the draft as > draft-ietf-jmap-jscontact. Barry confirmed it at RegExt session. Cheers, Mario PS: if you get some spare time, we can meet here at IETF. I'm leaving from Singapore today late in the evening. > > Cheers, > > Born. > > -- > � Bron Gondwana, CEO, Fastmail Pty Ltd > � brong@fastmailteam.com > > -- Dr. Mario Loffredo Servizi Internet e Sviluppo Tecnologico CNR - Istituto di Informatica e Telematica via G. Moruzzi 1, I-56124 PISA, Italy E-Mail: mario.loffredo@iit.cnr.it Phone: +39.0503153497 Mobile: +39.3462122240 Web: http://www.iit.cnr.it/mario.loffredo --------------CFC38EB6A0DD2811B47BA6FF Content-Type: text/html; charset=iso-8859-15 Content-Transfer-Encoding: 8bit
Hi Bron,

I apologize for having missed yesterday's presentation at JMAP but I arrived in Singapore late in the evening.

Due to some problems with my family, I couldn't book a flight to arrive earlier.

In addition to that, I seriously risked to stay in Italy because of the alert about a possible Arno's flood in Pisa.

I sincerely hope next presentation at JMAP is under better circustamces :-))

Il 20/11/2019 09:16, Bron Gondwana ha scritto:

Hi Mario and Robert,

The feedback from Singapore was largely "let's figure out what we're planning to do with names and addresses and then discuss specific text".

How would you best like to manage the discussion on each of those topics?� I'm happy to create Github issues, or we can do some example text on the mailing list.

I personally prefer to work on GitHub issues. They would allow us to link the issues once fixed to the release of a draft version.�

Unfortunately the recharter isn't quite complete yet, so I haven't accepted the draft into the working group, but once the charter comes through I will ask you upload a new version of the draft as draft-ietf-jmap-jscontact.

Barry confirmed it at RegExt session.

Cheers,

Mario

PS: if you get some spare time, we can meet here at IETF. I'm leaving from Singapore today late in the evening.

Cheers,

Born.

--

� Bron Gondwana, CEO, Fastmail Pty Ltd

� brong@fastmailteam.com

-- Dr. Mario Loffredo Servizi Internet e Sviluppo Tecnologico CNR - Istituto di Informatica e Telematica via G. Moruzzi 1, I-56124 PISA, Italy E-Mail: mario.loffredo@iit.cnr.it Phone: +39.0503153497 Mobile: +39.3462122240 Web: http://www.iit.cnr.it/mario.loffredo
--------------CFC38EB6A0DD2811B47BA6FF-- From nobody Wed Nov 20 03:21:50 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 7A7351208B9 for ; Wed, 20 Nov 2019 03:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=UZSULhg/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WjnYx2mm 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 UUj6itptpn72 for ; Wed, 20 Nov 2019 03:21:46 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F211208B1 for ; Wed, 20 Nov 2019 03:21:46 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 8C8F8434; Wed, 20 Nov 2019 06:21:45 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 20 Nov 2019 06:21:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:cc :subject:content-type; s=fm1; bh=zkNToCY4yADDnYfi/Rk+ZpdakUCUkCF JMZ667YWec7I=; b=UZSULhg/4SZCGGn651PIAWp+/hCR4EvMsGODfUClKfokYN8 ak6dfg0xecE0K30spT39VqHyFo+NR/0DxHifJP2ayUz3yFcyQjF/bj3MIIrmH8j7 hxy5YrcwhRdHRttW88UsFLiZ+R2f/sEid/kBbPconSthNbb5FRigdYx6eCSPkQzi 5suWg5fktxD0hCoKr+0aUH7F1NsbDrAq8LN+v9quhLw38YuEPS9rCqPE15vTOlru n8Cem8gvtZyrUKHK1zsnIMeOGUeVaJatmb0hvdACt4liu7Yn0D2fk3nLTvxPfgYF GFrx60CXKvirTQS6NuYvwgK7UNkbiGBVu4htRvg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=zkNToCY4yADDnYfi/Rk+ZpdakUCUk CFJMZ667YWec7I=; b=WjnYx2mmxh2124wZz10A9+sgnVFtAvcu85XWdQ2Gvybp9 sUStHIE7hAiPrjwhf3xMbh+dVJHmtZcfZgK0BQYvAnTqK/7Kmno8KythuV5Hi4Ex rxaJ+kAunMfj2w4sQEi3OP8vcOHgXWespxwXuP4zNRrnxPhQTu6R7VQayUtvUhQ+ iDDiEb+PtYdTIFqInHnD4hjxVp/QpTFTchN74qybzmcmKG6XM3OuADpGCcMHG/EC ieVc8Ttndszx+iLFMo7ptmQdsmUytiAFeS2uiv4QMTUjCyxtSfjQCVN3tUuweC6B yszlJ5+oUubvrtgnE7tUUBN0pxPxPjz+R4XSr50Jw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehtddgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhhonhcu ifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomheqne curfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdr tghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5C7ED30006F; Wed, 20 Nov 2019 06:21:44 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: Date: Wed, 20 Nov 2019 22:20:58 +1100 From: "Bron Gondwana" To: jmap@ietf.org Cc: =?UTF-8?Q?Ren=C3=A9_CORDIER?= , "Michael BAILLY" Content-Type: multipart/alternative; boundary=47d9b4a06dbb40d69680b348fa416ed4 Archived-At: Subject: [Jmap] Feedback on the quota draft 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, 20 Nov 2019 11:21:48 -0000 --47d9b4a06dbb40d69680b348fa416ed4 Content-Type: text/plain Hi, This is a combination of feedback collected from the meeting yesterday as well as my own suggestions! These suggestions only come with my own personal weight, and are not a "you must", they are an "I suggest" - please feel free to offer counter proposals or even outright rejections of my suggestions, there is no "chair weight" attached. With that said, here's the suggestions :) *Scope * I'm not sure if there's any point to it, but so long as it can be *null* (which might be the same thing as "account") then I don't see a problem in having it available for those who want it. I would just call the key "scope" rather than "usedScope". I don't see the point of putting different scopes on it, that seems unworkable. Instead, if you have quotas in multiple scopes I would expect a quota entry per scope with the amount that was used and the limit - e.g. "you're using 400Mb of 1Gb account quota, and your domain is using 34Gb of 100Gb allocated to the domain" - there's no point having "you're using 400Mb of your domain's 100Gb", because your domain could be using 99.9Gb and you'd have no way to see - so the "limit" needs to be the total minus what everyone else is using to be meaningful for calculating what you can do. *Datatypes * At the moment there's no way to tie datatypes to quotas. I would like to add an array of datatypes to each object (example below). As an example, you may have a different quota for Calendars than for Mail - or they may be shared. This is somewhat different from scope (server, domain, user, ...). *Quota/query * At the moment the only way to get the list of quotas is "Quota/get#ids: null". I think in the interests of consistency we should allow a /query as well (probably don't need a /queryChanges, just have a canCalculateChanges; false, but we could allow that too if a server finds it easy with their general model). *Quota/changes * Like with Mailbox/changes - I could see value in having a updatedProperties which can be either null or a list of properties, such that you could issue: [["Quota/changes", { "sinceState": ... }, "1"], ["Quota/get", { "#ids": { "resultOf": "1", "name": "Quota/changes", "path": "/updated" }, "#properties" : { "resultOf": "1", "Quota/changes", "path": "/updatedProperties" }, "2"]] Which might only need to fetch the "used" most of the time. *Push* There should be a nod towards Push and mention that Quota state changes are pushed like other state changes. *Description * Do we need to provide for both a short "name" and a longer "description" field on each quota? *Soft limits * Does anybody care about soft vs hard limits? Soft limit being "you won't be blocked, but you'll be told off any maybe charged more", hard limits being "your changes will be rejected". Should we have an optional second limit field in the spec? Something of this sort was raised on mailing list by John van der Kamp - in fact he talked of 3 levels. Perhaps they could be something like: warnLimit softLimit limit Where obviously warnLimit and softLimit are optional (and must each be lower than the next level up). This is more complexity, but it's optional complexity at both ends: servers don't need to set them, and clients don't need to display them. *Resource Types * The IMAP quota draft defines three types of resources for quotas, and also a registry where more can be described. The initial types are "STORAGE" (units 1024 octets), "MESSAGE" (number of individual emails) and "MAILBOX" (number of mailboxes). It maybe viable to use the same registry. Of course, then you get issues like what should you call it for Calendar or Addressbook? Should the limits be given DAVish names like "COLLECTION" and "RESOURCE" such that MESSAGE becomes "RESOURCE" and "MAILBOX" becomes "COLLECTION"? in JMAP quotas? Also: should we do storage in bytes, or do 1024 octets for our storage numbers in JMAP as well so they map identically to the definition in the registry? *EXAMPLE:* As promised, a Quota object for my example: { "id": "2a06df0d-9865-4e74-a92f-74dcc814270e", "type": "storage", "used": 105645, "scope": "account", "limit": 200000, "description": "Personal account usage", "name": "brong@brong.net", "datatypes" : [ "Mail", "Calendar", "Contact", "Todo" ], } And this would be displayed in a a box called "Quota Use": brong@brong.net 52% Something like that :) Cheers, Bron.* * -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --47d9b4a06dbb40d69680b348fa416ed4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi,

<= div style=3D"font-family:Arial;">This is a combination of feedback colle= cted from the meeting yesterday as well as my own suggestions! The= se suggestions only come with my own personal weight, and are not a "you= must", they are an "I suggest" - please feel free to offer counter prop= osals or even outright rejections of my suggestions, there is no "chair = weight" attached.

<= div style=3D"font-family:Arial;">With that said, here's the suggestions = :)

Scope

I'm not sure if there's an= y point to it, but so long as it can be null (which might be the = same thing as "account") then I don't see a problem in having it availab= le for those who want it.
I would just call the key "scop= e" rather than "usedScope". I don't see the point of putting diffe= rent scopes on it, that seems unworkable. Instead, if you have quo= tas in multiple scopes I would expect a quota entry per scope with the a= mount that was used and the limit - e.g. "you're using 400Mb of 1Gb acco= unt quota, and your domain is using 34Gb of 100Gb allocated to the domai= n" - there's no point having "you're using 400Mb of your domain's 100Gb"= , because your domain could be using 99.9Gb and you'd have no way to see= - so the "limit" needs to be the total minus what everyone else is usin= g to be meaningful for calculating what you can do.

Data= types

At the moment there's no way to tie datatypes t= o quotas. I would like to add an array of datatypes to each object= (example below). As an example, you may have a different quota fo= r Calendars than for Mail - or they may be shared. This is somewha= t different from scope (server, domain, user, ...).

Quot= a/query

At the moment the only way to get the list of= quotas is "Quota/get#ids: null". I think in the interests of cons= istency we should allow a /query as well (probably don't need a /queryCh= anges, just have a canCalculateChanges; false, but we could allow that t= oo if a server finds it easy with their general model).

<= b>Quota/changes

Like with Mailbox/changes - I could s= ee value in having a updatedProperties which can be either null or a lis= t of properties, such that you could issue:

[["Quota/chan= ges", { "sinceState": ... }, "1"],
["Quota/get", {
"#ids": { "resultOf": "1", "name": "Quota/changes", "path": "/updated" },
"#properties" : { "resultOf": "1", "Quota/changes", "path": "/updatedProperties" },
= "2"]]

Which might only need to fetch the "used" most of t= he time.

Push

There should be a nod= towards Push and mention that Quota state changes are pushed like other= state changes.

Description

Do we n= eed to provide for both a short "name" and a longer "description" field = on each quota?

Soft limits

Does any= body care about soft vs hard limits? Soft limit being "you won't b= e blocked, but you'll be told off any maybe charged more", hard limits b= eing "your changes will be rejected". Should we have an optional s= econd limit field in the spec?

Something of this sort was= raised on mailing list by John van der Kamp - in fact he talked of 3 le= vels. Perhaps they could be something like:

warnLim= it
softLimit
limit

Where obviously warnLimi= t and softLimit are optional (and must each be lower than the next level= up). This is more complexity, but it's optional complexity at bot= h ends: servers don't need to set them, and clients don't need to displa= y them.

Resource Types

The IMAP quota= draft defines three types of resources for quotas, and also a registry = where more can be described. The initial types are "STORAGE" (unit= s 1024 octets), "MESSAGE" (number of individual emails) and "MAILBOX" (n= umber of mailboxes). It maybe viable to use the same registry.
=

Of course, then you get issues like what should you call it = for Calendar or Addressbook? Should the limits be given DAVish nam= es like "COLLECTION" and "RESOURCE" such that MESSAGE becomes "RESOURCE"= and "MAILBOX" becomes "COLLECTION"? in JMAP quotas?

Also= : should we do storage in bytes, or do 1024 octets for our storage numbe= rs in JMAP as well so they map identically to the definition in the regi= stry?

EXAMPLE:

As promised, a Quota= object for my example:

<= /div>
{
"id": "2a06d= f0d-9865-4e74-a92f-74dcc814270e", "type": "storage", "used": 105645, "scope": "account", "limit": 200000, "description": "Personal account usage", "name": "brong@brong.net", "datatypes" : [ "Mail", "Calendar", "Contact", "Todo" ],
<= div style=3D"font-family:Arial;">}

And this would be disp= layed in a a box called "Quota Use":
brong@brong.net 52%

Something like that :)

Cheers,

B= ron.
--=
Bron Gondwana, CEO, Fastmail P= ty Ltd
brong@fastmailteam.com

--47d9b4a06dbb40d69680b348fa416ed4-- From nobody Wed Nov 20 03:24:42 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 743F31208B1 for ; Wed, 20 Nov 2019 03:24:40 -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=cVNnGKEw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hHosUxr8 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 3pKnWUKB-X59 for ; Wed, 20 Nov 2019 03:24:39 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525471208A7 for ; Wed, 20 Nov 2019 03:24:39 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 37539495 for ; Wed, 20 Nov 2019 06:24:37 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 20 Nov 2019 06:24:37 -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:subject:content-type; s=fm1; bh=XbF7Glb I9f8m9DjgQPMql/J/r9Gp3jGlBJElqMdfKLw=; b=cVNnGKEwD+aAXZgnTyGtQ7w 1U3tSQUc7B3CUiOhqJPqvvOZc7+omuzbaxzylARTJvkXU90GOtFchcBF15RVUOOL NYu9NwdQSYVUT0skNpL+viiLBW8ts5SOzuDCCaaWYq40uMcXRJpzb5GKRwAibfeB iv/TtKocU09MHaOphvf9+u4y0F7UR1nkKeY+koc04XAI/3djUKfttc4OPomj3fNv taK05hR7jG/h1apJP7Xwq1qFluVPZs+rqlpOynj0NhuSN5Zpfru3H4zqA9qyYGTg wCA9EqAUmoSZw3zXk+qvhbiKKgtMNkU1CBuCXx64x3qkCjpafQBZEvNcLfm10Ww= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=XbF7Gl bI9f8m9DjgQPMql/J/r9Gp3jGlBJElqMdfKLw=; b=hHosUxr8iIVJ+RwWTYmYna Q8YvnH8Y99DDhFNuu3RerPft3jtZ9e+AZ0JV1CZepJs1mmYjl2eVTDTq5MXuF7hU UOegrbyvqLqNoZxwMa/AnGLFaIhc+2SEzwu5fHRMwG8CVDH++R6vkjLPdhUUQhbc 9E9+GO95qyw7t29/B3tGC8A0m3L+lJNKzVpLbCHAV8suNsQcYERE43TkyILljS9y ZvXrBH0EVT8lzcK6BdGpZ+XJpHxrY5oadEDCrR//MSCYMvGtEMrkFallq76T2kc2 hPfSvMOg56yg/mj6SwfCBvlt/l3hMFSSm4RQGSnugmy5KgwEZkvYh20tr/nsEGdw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehtddgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepsg hrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgep td X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8956930006F; Wed, 20 Nov 2019 06:24:36 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <88e8980b-bd85-4056-88d6-50ee9683e730@dogfood.fastmail.com> In-Reply-To: References: Date: Wed, 20 Nov 2019 22:24:33 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=14d8a0c48d70405c8b5af1680f2c2b90 Archived-At: Subject: Re: [Jmap] Feedback on the quota draft 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, 20 Nov 2019 11:24:40 -0000 --14d8a0c48d70405c8b5af1680f2c2b90 Content-Type: text/plain On Wed, Nov 20, 2019, at 22:20, Bron Gondwana wrote: > With that said, here's the suggestions :) I should add - as promised in an earlier missive - here's the entire tiny Quota spec for Fastmail. We would clearly convert over to the published spec, probably using the "mail" and "files" as the short "name" field for each of our Quota types. The "mail" would have datatype [ "Mail", "Mailbox", "Calendar", "Contacts"] or so. Cheers, Bron. # Quotas A **Quota** object has the following properties: - **used**: `Number` Storage used in MB, rounded to the nearest MB - **total**: `Number` Total storage available in MB, rounded to the nearest MB ## Quota/get Standard */get* method. The *ids* argument may be `null` to fetch all at once. Objects with the following ids exist in FastMail: -`mail`: Mailbox quota (used for mail, calendars and contacts) -`files`: Files quota **Note**: The server may at any time add an unrequested *Quota/get* response to the list of responses it sends to the client, if it thinks the usage may have changed. --14d8a0c48d70405c8b5af1680f2c2b90 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

On Wed, Nov 20, 2019, at 22:20, Bron G= ondwana wrote:
With that said, here's the suggestions :)
=

I should add - as p= romised in an earlier missive - here's the entire tiny Quota spec for Fa= stmail. We would clearly convert over to the published spec, proba= bly using the "mail" and "files" as the short "name" field for each of o= ur Quota types. The "mail" would have datatype [ "Mail", "Mailbox"= , "Calendar", "Contacts"] or so.

Cheers,

Bron.

# Quotas

A **Quota** object has the following pr= operties:

- **used**: `Number`
Storage used in MB, round= ed to the nearest MB
- **total**: `Number`
Tota= l storage available in MB, rounded to the nearest MB

=
## Quota/get<= span style=3D"font-family: menlo, consolas, monospace, sans-serif;" clas= s=3D"font">

Standar= d */get* method. The *ids* argument may be `null` to fetch all at once.<= /span>

Ob= jects with the following ids exist in FastMail:

-`mail`: Mailbox quota (= used for mail, calendars and contacts)
-`files`: Files quota

**= Note**: The server may at any time add an unrequested *Quota/get* respon= se to the list of responses it sends to the client, if it thinks the usa= ge may have changed.
<= br>

--14d8a0c48d70405c8b5af1680f2c2b90-- From nobody Wed Nov 20 06:14:12 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 A8067120896; Wed, 20 Nov 2019 06:14:05 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <157425924564.30512.117370402366303624@ietfa.amsl.com> Date: Wed, 20 Nov 2019 06:14:05 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-03.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, 20 Nov 2019 14:14:06 -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-03.txt Pages : 9 Date : 2019-11-20 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mdn-03 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 Nov 20 08:10:40 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 58B0712084B for ; Wed, 20 Nov 2019 08:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Jak0CIyl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=R9AZbBId 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 zkSUtQREVYjS for ; Wed, 20 Nov 2019 08:10:36 -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 65B00120842 for ; Wed, 20 Nov 2019 08:10:36 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id A211960F; Wed, 20 Nov 2019 11:10:35 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 20 Nov 2019 11:10:35 -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=6lT1 zblAeoAaquB9K9O6u7hCsFGy344ypmZPw+Z6eC4=; b=Jak0CIylDM13FmpThulu /bETbWxnqvi18hRk/HIQwI2peu4WeeJz2mzlrhV92Pyekvz/YzPpkHRsRs5T4qtc x7kbbttwa572DfnADhFQ21WGPSmDl8p+IT4KwXBFZ+kuBF/hXQKjhgGaTbj5Ss7a MBGlzdJyutxi6u386ku0g2UuG213PSFzgcHXLjy4HagBv41eqnPEciJob9cg0Ahd VBS9GAXkYdNkh+XEOwQVX7/Y8u/FrTy9Wjgu9nHmsk3+WfWD1ZdP7g7pJHjyTpr+ d4joHeac195K6ZWYSYls4hgoE79MnD4EXRCz8yu2f019Ka/4iUQpLiMWh6qXsvw3 Sg== 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=6lT1zb lAeoAaquB9K9O6u7hCsFGy344ypmZPw+Z6eC4=; b=R9AZbBIdxMRuiERicHMT3i 17TwIq3jQX52jh3pJP+wHyNkTgCCIl+iatOQAfVMMNLTJb4zF4p4h2pAq1/aKgre KIAiHYzvq7++i3G6x/zY3zHU5q//Pb61e9J5QqfCFnTD/F6nqfxFrpl1wz6eM/Iv Qmd3qMgiEXbz603oLNdcB1CJDftlwBnwqu/JIgilf9mIxffmNg53Lcedkq67kNC+ thaJPA2j1TJqAb2mHqwUrgJaEzRQ4oVcHbhBgga9BCokQCk1t5vaFc1ZCmW+I5oi OawmSL3RlCAzJ2FOVxDNgxs0U7ghrqnb4hwAxgz90zc3aw8O5850jw5kNjzyyYtQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehtddgkeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggr mhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8034030006F; Wed, 20 Nov 2019 11:10:34 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <4067bcdb-ff15-4c52-bba4-b324cfa6c132@www.fastmail.com> In-Reply-To: <5cc18f1b65d00bb022c3cf50d6884efc@linagora.com> References: <4b5ccf06-1056-44e6-9192-ec88f6d092b7@dogfood.fastmail.com> <5cc18f1b65d00bb022c3cf50d6884efc@linagora.com> Date: Thu, 21 Nov 2019 03:10:31 +1100 From: "Bron Gondwana" To: "Raphael OUAZANA" Cc: jmap@ietf.org Content-Type: multipart/alternative; boundary=408b0094b03947d58e0dfbb3269be6b3 Archived-At: Subject: Re: [Jmap] MDN: is it ready for last call 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, 20 Nov 2019 16:10:38 -0000 --408b0094b03947d58e0dfbb3269be6b3 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry to hear you had mail problems last week - thanks for getting back = to me quickly today! Great - I'll call a last-call on it tomorrow :) Cheers, Bron. On Thu, Nov 21, 2019, at 01:19, Raphael OUAZANA wrote: > Hi Bron, >=20 > Thank you for your message, and sorry to not be able to attend the=20 > meeting yesterday. >=20 > Le 2019-11-20 09:13, Bron Gondwana a =C3=A9crit : > > Hi Raphael, > >=20 > > Sorry - I dropped the ball on MDN. It looks from the Montreal notes > > like it's ready for working group last call. Are you aware of any > > outstanding issues or questions? > >=20 > > If so - let's get another draft out. If not, let's get to last call > > soon! >=20 > I'm not aware on any issue on it, so I just submitted a new version of= =20 > the draft. The only change is the replacement of draft-jmap-mail by th= e=20 > RFC reference. >=20 > > I said on the milestones doc that we expect to send to IESG during > > December, so I'd appreciate getting it to last call quickly. >=20 > Hope so too! >=20 > Regards, > Rapha=C3=ABl. > PS : I tried to send an email last week about the status of my draft,=20= > but it did not reach the list (seems I have some issues posting on som= e=20 > mailing lists with this address (sic...)). >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --408b0094b03947d58e0dfbb3269be6b3 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sorry to hear you had mail problems last week - thanks for= getting back to me quickly today!

Great - I'll call a la= st-call on it tomorrow :)
Cheers,

Bron.

On Thu, Nov 21, 2019, at 01:19, Raphael OUAZANA wrote:
Hi Bron,

Thank you for your message, and sorry to n= ot be able to attend the
meeting yesterday.

Le 2019-11-20 09:13, Bron Gondwana a= =C3=A9crit :
> Hi Ra= phael,
>
> Sorry - I dropped the ball on MDN.&= nbsp; It looks from the Montreal notes
> like it's ready for working group last call. Are yo= u aware of any
> outstandi= ng issues or questions?
>&= nbsp;
> If so - let's get = another draft out. If not, let's get to last call
> soon!

I'm not aware on an= y issue on it, so I just submitted a new version of
the draft. The only change is the replaceme= nt of draft-jmap-mail by the
RFC reference.

> I said on the milestones doc th= at we expect to send to IESG during
> December, so I'd appreciate getting it to last call quickly.=

Hope so too!
=
Regards,
Rapha=C3=ABl.
PS : I tried to send an email last week about the status of my = draft,
but it did not r= each the list (seems I have some issues posting on some
<= div style=3D"font-family:Arial;">mailing lists with this address (sic...= )).

Bron Gond= wana, CEO, Fastmail Pty Ltd

bro= ng@fastmailteam.com

--408b0094b03947d58e0dfbb3269be6b3-- From nobody Wed Nov 20 19:27:42 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 770741207FF for ; Wed, 20 Nov 2019 19:27:40 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157430686048.1009.1162928335959348836.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2019 19:27:40 -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, 21 Nov 2019 03:27:40 -0000 Changed milestone "Submit JMAP Quotas document to the IESG", set state to active from review, accepting new milestone. Changed milestone "Submit JMAP SMIME validation document to the IESG", set state to active from review, accepting new milestone. Changed milestone "Adopt a document for SMIME key management and server side signing", set state to active from review, accepting new milestone. Changed milestone "Adopt a document defining JMAP access to addressbooks", set state to active from review, accepting new milestone. Changed milestone "Submit JMAP Calendars document to the IESG", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Wed Nov 20 19:29:19 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 D557C12091F for ; Wed, 20 Nov 2019 19:29:17 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157430695786.1114.10088431949109619948.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2019 19:29:17 -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, 21 Nov 2019 03:29:18 -0000 Changed milestone "Submit JMAP SMIME validation document to the IESG", set description to "Submit JMAP S/MIME signature validation document to the IESG". Changed milestone "Adopt a document for SMIME key management and server side signing", set description to "Adopt a document for S/MIME key management and server side signing/encryption". URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Wed Nov 20 19:34: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 C801712091F for ; Wed, 20 Nov 2019 19:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=HkxdNVJu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fqoSJv1k 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 5hh7kVkEQGqs for ; Wed, 20 Nov 2019 19:34:38 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F121208B3 for ; Wed, 20 Nov 2019 19:34:38 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5591722405 for ; Wed, 20 Nov 2019 22:34:37 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 20 Nov 2019 22:34:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm1; bh=JK1APxFZjxIdgvTCZVaFFDhc7/20dfyQJCE6hEw s7Ec=; b=HkxdNVJufPWXJxxtiEutJdNZjeNSWSQ0SRepqkXMzHa/8P/Ik3msWiy miPEd3N5l4dVj2d+Yd6HBKycKDGpMHzXankZaGzuz8sssdj4IaS0B9Ju5lpNNH1q OlOpLldeGEn0IbvXdCJ7vhz/x9P5MhicOKvqojQtQq690eNdtRtlPwCDpV3LWDBN /3QfQUbYFBZ27Daz39q9x+9TstslO+Eed1ndps7+jC6x0QhN2FkINGmrgigr7HEP 9QZcAZejcQAE3ByKxze0/sfNGHnuTwwwrY+8XWSf8i7w5yn2d6FDuzpjqotxpzXu 8zdcbmXYP0YnzXX/Hb7kgK5otXnoEFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=JK1APxFZjxIdgvTCZVaFFDhc7/20d fyQJCE6hEws7Ec=; b=fqoSJv1k8zE6AMbUmSoYoPI0RnKAB0R6OmH82EU6aE7PV FgSOwj9szQ1dq2QTtjPJWG7/PB2iYKE3rxHdWZuYq7p238rT/zOZvgk6o61JnEKW rydetTDsdfUY7UxOMN2E4823eVPo1e9enylbszaXwg6I0FNagkknEL+aXiCFCSyb gb9+0YF8DMBp187KS2T8xzIiKf+fk396pt90/nBDir+HAd/4imb+1eXA5D9151c3 W9X/mBAB6vSZ59oYYBsK+Kt2p1gGzGjg7ns7dr71iakJX/oAUijn+uhvQ7PsiNRM EzY8EdhfSAMITaXt3+xob/lDNPc556FKpayutI7mw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehuddgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepsghroh hnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy:

Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0D1D230006F; Wed, 20 Nov 2019 22:34:37 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <1776898c-03ee-4d34-b254-a9c638dd3741@dogfood.fastmail.com> Date: Thu, 21 Nov 2019 14:34:32 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=26eb6db3e7fd4a39b85489462ba3b649 Archived-At: Subject: [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: Thu, 21 Nov 2019 03:34:40 -0000 --26eb6db3e7fd4a39b85489462ba3b649 Content-Type: text/plain Thanks Raphael for uploading a new draft that updates the references to the published RFCs. This email starts a working group last call, which will expire on Sunday December 8th (a little over 2 weeks from now). At that point the documented will be submitted to the IESG for publication unless problems are uncovered during the last call. If you have any issues with this document, now is the time to raise them! Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --26eb6db3e7fd4a39b85489462ba3b649 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Thanks Raphael for uploading a new draft that updates the = references to the published RFCs.

This email starts a wor= king group last call, which will expire on Sunday December 8th (a little= over 2 weeks from now). At that point the documented will be subm= itted to the IESG for publication unless problems are uncovered during t= he last call.

If you have any issues with this document, = now is the time to raise them!

Cheers,

Bron.

--
<= /div>

Bron Gondwana, CEO, Fastmail Pty Lt= d

brong@fastmailteam.com

--26eb6db3e7fd4a39b85489462ba3b649-- From nobody Wed Nov 20 19:42:25 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 6A63D12093A for ; Wed, 20 Nov 2019 19:42:23 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157430774343.724.17820254380919016679.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2019 19:42:23 -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, 21 Nov 2019 03:42:23 -0000 Changed milestone "Submit Message Disposition Notification document to the IESG", added draft-ietf-jmap-mdn to milestone. URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Thu Nov 21 03:11:43 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 A0342120844 for ; Thu, 21 Nov 2019 03:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 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, URIBL_BLOCKED=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 FEYQrFCYgfup for ; Thu, 21 Nov 2019 03:11:41 -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 F1FD31200C1 for ; Thu, 21 Nov 2019 03:11:40 -0800 (PST) Received: from linagora.com (unknown [10.233.69.202]) by outgoing.linagora.com (Postfix) with ESMTP id 481E73B; Thu, 21 Nov 2019 11:11:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1574334698; bh=1aox8fjani7uMehuP9W4SI/lqIeqi/zuKWPlxwyfh9o=; h=From:Reply-To:To:Subject:Date:References:From; b=WHGo9Q905VnCI3GL+noy01/l5fLhgwRL4sHPO/rREjcb6GgTCAAiaYAb2igb1v8lB VB3TZjd17N10PlgtSQl69URSAgWRbpSuIYZepbHg52FAvGCqfMM9x77ge7OuAg8fK0 H7Xq8Kt6ILAArIE9NIfEeEv1E3RvcwqvUAAha8BShGbg7rgYGvHD1MV0ZXoWTFiauz HCNgRilNy81/ntu+UIfrC+wBZQW3a3HZe9hbqxExBtb1DgaoFHm3jMrYcLVhnSv0tr 2WT54ahZ0iMfH2/WDYxU7JG1snrzuUsWVq4Tr5nNGPGBwEEeqt1uln5eiZ8OB32lHm 63ZFVP/62O+ww== MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Ren=E9_CORDIER?= Sender: =?ISO-8859-1?Q?Ren=E9_CORDIER?= Reply-To: rcordier@linagora.com To: "jmap@ietf.org" , Bron Gondwana Message-ID: Date: Thu, 21 Nov 2019 11:11:36 +0000 References: Archived-At: Subject: Re: [Jmap] Feedback on the quota draft 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, 21 Nov 2019 11:11:42 -0000

Hi Bron, hi the Jmap community,

First of all, I apologize for = not being present at the meeting, and for forgetting to send a notice abou= t it=2E I will try to do better in the future !

Then, thanks a lot f= or all your feedbacks=2E Some make total sense to me, some others we might = need to think a bit more and discuss=2E I will come back towards you after = we take the proper time to analyze all of this=2E

Cheers,

Rene= =2E

Le 20 novembre 2019 18:20, de brong@fastmailteam=2Ecom

Hi,
=

This is a combination of feedback collected from the meeting yesterday a= s well as my own suggestions! These suggestions only come with my own= personal weight, and are not a "you must", they are an "I suggest" - pleas= e feel free to offer counter proposals or even outright rejections of my su= ggestions, there is no "chair weight" attached=2E

With that sai= d, here's the suggestions :)
Scope

I'm not= sure if there's any point to it, but so long as it can be null (whi= ch might be the same thing as "account") then I don't see a problem in havi= ng it available for those who want it=2E

I would just call the = key "scope" rather than "usedScope"=2E I don't see the point of putti= ng different scopes on it, that seems unworkable=2E Instead, if you h= ave quotas in multiple scopes I would expect a quota entry per scope with t= he amount that was used and the limit - e=2Eg=2E "you're using 400Mb of 1Gb= account quota, and your domain is using 34Gb of 100Gb allocated to the dom= ain" - there's no point having "you're using 400Mb of your domain's 100Gb",= because your domain could be using 99=2E9Gb and you'd have no way to see -= so the "limit" needs to be the total minus what everyone else is using to = be meaningful for calculating what you can do=2E

Datatypes

At the moment there's no way to tie datatypes to quotas=2E&n= bsp; I would like to add an array of datatypes to each object (example belo= w)=2E As an example, you may have a different quota for Calendars tha= n for Mail - or they may be shared=2E This is somewhat different from= scope (server, domain, user, =2E=2E=2E)=2E

Quota/query
<= /b>

At the moment the only way to get the list of quotas is "Quota/= get#ids: null"=2E I think in the interests of consistency we should a= llow a /query as well (probably don't need a /queryChanges, just have a can= CalculateChanges; false, but we could allow that too if a server finds it e= asy with their general model)=2E

Quota/changes
=

Like with Mailbox/changes - I could see value in having a updatedPropert= ies which can be either null or a list of properties, such that you could i= ssue:

[["Quota/changes", { "sinceState": =2E=2E=2E }, "1"],
=
["Quota/get", { =
"#ids"= : { "resultOf": "1", = "name": "Quota/changes", "path": "/upda= ted" },
"#properties" : { "resultOf": "1", "Quota/changes", = "path": "/updatedProperties" = },
"2"]]

Which m= ight only need to fetch the "used" most of the time=2E

Push=

There should be a nod towards Push and mention that Quota = state changes are pushed like other state changes=2E

Descrip= tion

Do we need to provide for both a short "name" and a lo= nger "description" field on each quota?

Soft limits
<= /div>

Does anybody care about soft vs hard limits? Soft limit being= "you won't be blocked, but you'll be told off any maybe charged more", har= d limits being "your changes will be rejected"=2E Should we have an o= ptional second limit field in the spec?

Something of this sort = was raised on mailing list by John van der Kamp - in fact he talked of 3 le= vels=2E Perhaps they could be something like:

warnLimit
softLimit
limit

Where obviously warnLimit and softLim= it are optional (and must each be lower than the next level up)=2E Th= is is more complexity, but it's optional complexity at both ends: servers d= on't need to set them, and clients don't need to display them=2E
<= div style=3D"font-family:Arial;">
Resource Types

The IMAP quota draft defines three type= s of resources for quotas, and also a registry where more can be described= =2E The initial types are "STORAGE" (units 1024 octets), "MESSAGE" (n= umber of individual emails) and "MAILBOX" (number of mailboxes)=2E It= maybe viable to use the same registry=2E

Of course, then you g= et issues like what should you call it for Calendar or Addressbook? S= hould the limits be given DAVish names like "COLLECTION" and "RESOURCE" suc= h that MESSAGE becomes "RESOURCE" and "MAILBOX" becomes "COLLECTION"? in JM= AP quotas?

Also: should we do storage in bytes, or do 1024 oct= ets for our storage numbers in JMAP as well so they map identically to the = definition in the registry?

=
EXAMPLE:

As prom= ised, a Quota object for my example:

{
"id":= "2a06df0d-9865-4e74-a92f-74dcc814270e", "type": "storage", "used= ": 105645, "scope": "account", "limit": 200000, "description= ": "Personal account usage", "name": "brong@brong=2Enet", "datatypes" : [ "Mail", "Calendar", "Cont= act", "Todo" ],
}

An= d this would be displayed in a a box called "Quota Use":
brong@brong= =2Enet 52%

Something like that :)

Cheers,

Bron=2E
--
Bron Gondwana, CEO, Fastma= il Pty Ltd
brong@fastmailteam=2Eco= m

From nobody Thu Nov 21 04:44:44 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 2DCEB1208BA for ; Thu, 21 Nov 2019 04:44:42 -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=JCZ+MOhW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WkP/GV8Q 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 jHNG2RnZI0Ja for ; Thu, 21 Nov 2019 04:44:40 -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 A41BC1208B9 for ; Thu, 21 Nov 2019 04:44:40 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C289A21FC3 for ; Thu, 21 Nov 2019 07:44:39 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Thu, 21 Nov 2019 07:44:39 -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:subject:content-type; s=fm1; bh=fWyxAtR Aa4Gr/vyHuUaZNlUEg8bMLFm3E9AtazwRoaU=; b=JCZ+MOhWCMBeRFLNok4KBZ6 Qa8tif9T3JiViQNUAWCMHiBxXrCD7mVOCRUODdlKIL/gqHcjR4bvZOJtrB6ubXpA +bZ9/OzAqVW6Mw0RctHtobBjgI+1O5uvtRjImUSysM8qZ0Iicz1Bp71BhLYkjl+X qjG4S0iigeid4rVG9IQqFwqLpLIE7W5m3itSyT3+UYiCWMTzYSnLlZlVURGiA8Uy tBlQDQvk4m+0th0YT0CtJPSYXcGUmd1kfQSSlxsS7WR+x3cpjjiv/hRlnWrNzBnU utJuXz70zRvXvrd8Co7GBGzZLEcgs7DKs3we47I8wOO22S0W6qV4f5r5fV44eCQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=fWyxAt RAa4Gr/vyHuUaZNlUEg8bMLFm3E9AtazwRoaU=; b=WkP/GV8QiU4QFfwR2Ht2/m kAlWcAEpjKK/hTwYt/C2VYxPyu4vgCadppYoVOc1szRSjfEdMIBsn23dtWNtsrLv 4t1HwzLmEdqijlG1fbXjuKssb18EVPcHpGDDgh2Nxv4JTb9BM08EtaN+vm89Jp0L lxnoUjdlmtjhYEjv3EeYuw0YB+GzURpG6XcbVorXX6W5Q3vgjdrc5omikR8GRV4C plM/rlLI5VXi0F/rpciP2Iyq7RkPWhVVSZkyrNVyg367DNV3F6pqvkvUMmA3xKlv BkzaYbremEJFR5RM6qGjfUkAPJ04jRc9RkHMV7IamEhXdWsCCV6DbVz/uE3SfJQA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehvddggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghm rdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 71C1030045A; Thu, 21 Nov 2019 07:44:39 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 21 Nov 2019 20:44:19 +0800 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=2053f58bfd004240b05a302efe4de023 Archived-At: Subject: Re: [Jmap] Feedback on the quota draft 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, 21 Nov 2019 12:44:42 -0000 --2053f58bfd004240b05a302efe4de023 Content-Type: text/plain On Wed, 20 Nov 2019, at 19:20, Bron Gondwana wrote: > *Resource Types* > > The IMAP quota draft defines three types of resources for quotas, and also a registry where more can be described. The initial types are "STORAGE" (units 1024 octets), "MESSAGE" (number of individual emails) and "MAILBOX" (number of mailboxes). It maybe viable to use the same registry. > > Of course, then you get issues like what should you call it for Calendar or Addressbook? Should the limits be given DAVish names like "COLLECTION" and "RESOURCE" such that MESSAGE becomes "RESOURCE" and "MAILBOX" becomes "COLLECTION"? in JMAP quotas? This is completely redundant if we have the data types property that you mentioned earlier (which I think we should do). The only thing you need is a property to say whether this quota is a "count" or "bytes". e.g. You may have a quota of max 50 Calendar objects and another quota that limits Email and CalendarEvent storage to a shared 50 GB. > Also: should we do storage in bytes, or do 1024 octets for our storage numbers in JMAP as well so they map identically to the definition in the registry? I would prefer bytes. Neil. --2053f58bfd004240b05a302efe4de023 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, 20= Nov 2019, at 19:20, Bron Gondwana wrote:
Resource Types

The IMAP quota draft defines three types of resources for = quotas, and also a registry where more can be described. The initi= al types are "STORAGE" (units 1024 octets), "MESSAGE" (number of individ= ual emails) and "MAILBOX" (number of mailboxes). It maybe viable t= o use the same registry.

=
Of course, then you get issues l= ike what should you call it for Calendar or Addressbook? Should th= e limits be given DAVish names like "COLLECTION" and "RESOURCE" such tha= t MESSAGE becomes "RESOURCE" and "MAILBOX" becomes "COLLECTION"? in JMAP= quotas?

This is completely re= dundant if we have the data types property that you mentioned earlier (w= hich I think we should do). The only thing you need is a property to say= whether this quota is a "count" or "bytes". e.g. You may have a quota o= f max 50 Calendar objects and another quota that limits Email and Calend= arEvent storage to a shared 50 GB.

Also: should we= do storage in bytes, or do 1024 octets for our storage numbers in JMAP = as well so they map identically to the definition in the registry?

I would prefer bytes.

Neil.

--2053f58bfd004240b05a302efe4de023-- From nobody Thu Nov 21 20:52:18 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 D849C120103 for ; Thu, 21 Nov 2019 20:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=SSpQTCLD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=e//u66Pc 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 WqqeLCtWYp9h for ; Thu, 21 Nov 2019 20:52:14 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B78912002F for ; Thu, 21 Nov 2019 20:52:14 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 85033101C for ; Thu, 21 Nov 2019 23:52:13 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Thu, 21 Nov 2019 23:52:13 -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:subject:content-type; s=fm1; bh=hlh48cY xevsKSs1B+PK31MARObjxmyzFo/MmXmt2mkU=; b=SSpQTCLDAmT73KKUOk1JVxT I2HWZ/KyWW4IiahqHq5GSkI0NRRvTRyD1B39JkPM63rDpBsG5aZH1cZYi0R1/Gyd lXM3mAdmfwzfL46QVXLCX58Rb+MjyqPqkagdDtBfiVCxFVoxC2JuPvC3ZLdrUCeF m6UIBsyZKD2wgWePAkCCmLrjLLuP4O2sYsDQ4YLPPdq7dl7gb3YFGNMysB7YrUoN 1fqX/CUKLqb6+lIE0Ik6aSVMWZYU7xPlAmvtxdG9Lyks5yXN61dwPU9X2W3GnRaF JjmccWqXSEsm725yaob/6KZpSky3A6COYyToHm6zyujYS9y/k8drivgHO05km8Q= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hlh48c YxevsKSs1B+PK31MARObjxmyzFo/MmXmt2mkU=; b=e//u66PcMZp9o5QaJ/mgbN Kf5rIMg1YiWJ8qEdfKSaP+m1Kf/7Kzp9ocjmQtkLW+npjXVkIf5n0qVMOQI9dJqN ET0Nj1tD51QCpiYGxyAV7TylBAny2e4t1OftdGyaWNsPkiAIu+lcqEiIf8/Tyeiy EuY8EJnJJIAHfsFjNXxCwZPsdQg1TegLP+YhXb2+NNTdFunUyZFKOnH6fnQFthvb /umChX4g+NZoBFnIDFRSlMUH2z5vECFQoFjS/LapDHRBUPkyXUVqVsUk4wPgZY52 Dvjba7TDNJ4z7BL4BhJ+2hyU2DpnxYtk8y4dzgBhPmjlWR906+vOLfMVrQn8WMvw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehfedgjeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehn vghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AE8D1300DCB; Thu, 21 Nov 2019 23:52:12 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <1776898c-03ee-4d34-b254-a9c638dd3741@dogfood.fastmail.com> References: <1776898c-03ee-4d34-b254-a9c638dd3741@dogfood.fastmail.com> Date: Fri, 22 Nov 2019 12:51:52 +0800 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=9d99670f60c64a978cc398bd1c44f75f 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: Fri, 22 Nov 2019 04:52:16 -0000 --9d99670f60c64a978cc398bd1c44f75f Content-Type: text/plain Overall I think this doc is good. A few nits: > o forEmailId: "String" Email Id of the received email this MDN is relative to. This needs to be nullable, as described in MDN/parse. > o originalMessageID: "String|null" (server-set) I think this should be *originalMessageId* (lowercase d on the end) for consistency. > * > 2.1 . MDN/set * > Standard "/set" method as described in [RFC8620 ] where only the _create_ parameter is supported. This is not quite right: the "accountId" and "ifInState" arguments are fine. I think this text should say something like: > Only create is supported; any attempt to update/destroy MUST be rejected with a "forbidden" SetError. And as a general comment, in the final versions of RFC8620/8621 we cleaned up the formatting so it worked better in the plain text version of the RFCs; I suggest adopting the same. So we use "quote" for a property name reference (not _underscore_) and remove the *asterisks* around the property names in the definitions. Cheers, Neil. --9d99670f60c64a978cc398bd1c44f75f Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Overall I = think this doc is good. A few nits:

o forEmailId: "String= " Email Id of the received email this MDN is relative to.

This needs to = be nullable, as described in MDN/parse.

o originalMe= ssageID: "String|null" (server-set)

I think this should be originalMessageId (lowercase d = on the end) for consistency.

=
2.1. MDN/set
Standard "/set" method as described in [RFC8620] where only the _create_ parameter is supported.
This is not quite right: the "accountId" and "ifInState" arg= uments are fine. I think this text should say something like:
<= div>
Only create is supported; a= ny attempt to update/destroy MUST be rejected with a "forbidden" SetErro= r.

And as a general comment, i= n the final versions of RFC8620/8621 we cleaned up the formatting so it = worked better in the plain text version of the RFCs; I suggest adopting = the same. So we use "quote" for a property name reference (not _undersco= re_) and remove the *asterisks* around the property names in the definit= ions.

Cheers,
Neil.
<= /html> --9d99670f60c64a978cc398bd1c44f75f-- From nobody Thu Nov 21 21:19:22 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 1D80C120288 for ; Thu, 21 Nov 2019 21:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=rrzdhB6a; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qoQlKuQc 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 bta7zUBUNvJQ for ; Thu, 21 Nov 2019 21:19:19 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594E112022D for ; Thu, 21 Nov 2019 21:19:19 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 9E9D810DC; Fri, 22 Nov 2019 00:19:18 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Fri, 22 Nov 2019 00:19:18 -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=lTF1 omGVeDBVOwAMd2HNtR28QzuLMmPkSb/E1gkbvgI=; b=rrzdhB6aPA3eP4/3VzXy J7RAniJ1BhWcusUh7i5m421zHeBARroUfRJQ5tI+XqEIjLrdxGXllTwPRdvmQz8Y gY68FtmKfbYqXxNEY1gFfHC773FfdXEzm/Oe9nr0+HeBzf1c0QCgCPWuQkrtDZ6i OrVtqFTqEgBPMALSkF/7deZNvgAUI3qnZXvnF75xlF034y9p95BP+TWFNJ/o1tYO PM1/7Soa0CfnZIBg4PBHgsYwFHJVmUIBNSyZBKClAOtV4Q1LLwbp3E4Y6C7nEbUz w99lP33JZB2Q54G2hcULItm17dCUgrWviKH3+WDS43CJi0vDdWAQu4fCB54Fxyfg ug== 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=lTF1om GVeDBVOwAMd2HNtR28QzuLMmPkSb/E1gkbvgI=; b=qoQlKuQcUxlWTig2nMiISA kGDaLGZqWcfw2ugdzLqv1kjyHZPxAeddmrTrFaz0VyiYd95RkMbE34HGp4pse12A 2rZc3WTSnG71egsHvAqgDR8FpFc7HPXEQ7TZnCWr/Bb/3zHx6/MtA2s6kF80Iofu 4OozcGfCgthIWqkgMP8AHo9ke1bRIOmgFLNYCJXg0iqyYyh1W0IsWHamUa+CCOaf GHh8g+I3kIrLTQVDax2XZtbvbWhfAwnednHKmVtDIOdG7X5t8TFKCpI/yRKW+z9B 7sU0nWVtMuttMDodFjROhYUc+bQBD9eXKVyVAwi2XiDf1HiJ+Pq/pdwZrfe8xn4w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehfedgkedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuffhomhgrihhnpehivghtfhdrohhrghdpihgvthhfrddrohhrghenucfrrghrrghm pehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuve hluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C0A12300DFE; Fri, 22 Nov 2019 00:19:17 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <5365e458-8fe8-4bf2-9b5c-5a1ea386b79c@dogfood.fastmail.com> In-Reply-To: References: <1776898c-03ee-4d34-b254-a9c638dd3741@dogfood.fastmail.com> Date: Fri, 22 Nov 2019 16:19:14 +1100 From: "Bron Gondwana" To: jmap@ietf.org Cc: "Raphael OUAZANA" Content-Type: multipart/alternative; boundary=80eef5da27dd43788dd880e9d315b5fe 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: Fri, 22 Nov 2019 05:19:21 -0000 --80eef5da27dd43788dd880e9d315b5fe Content-Type: text/plain Raphael, With my chair hat on - I'm happy for you to either issue drafts with updates during the last call period, or wait until the end and issue another draft containing all the feedback at the end of the last call period. 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 agree that it's been addressed in the final draft! Cheers, Bron. On Fri, Nov 22, 2019, at 15:51, Neil Jenkins wrote: > Overall I think this doc is good. A few nits: > >> o forEmailId: "String" Email Id of the received email this MDN is relative to. > > This needs to be nullable, as described in MDN/parse. > >> o originalMessageID: "String|null" (server-set) > > I think this should be *originalMessageId* (lowercase d on the end) for consistency. > >> 2.1 . MDN/set >> Standard "/set" method as described in [RFC8620 ] where only the _create_ parameter is supported. > > This is not quite right: the "accountId" and "ifInState" arguments are fine. I think this text should say something like: > >> Only create is supported; any attempt to update/destroy MUST be rejected with a "forbidden" SetError. > > And as a general comment, in the final versions of RFC8620/8621 we cleaned up the formatting so it worked better in the plain text version of the RFCs; I suggest adopting the same. So we use "quote" for a property name reference (not _underscore_) and remove the *asterisks* around the property names in the definitions. > > Cheers, > Neil. > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --80eef5da27dd43788dd880e9d315b5fe Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Raphael,
<= br>With my chair hat on - I'm happy for you to either issue drafts with = updates during the last call period, or wait until the end and issue ano= ther draft containing all the feedback at the end of the last call perio= d.

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

Cheers,

Bron.

On Fri, Nov 22, 2019, at 15:51, Neil Jenk= ins wrote:
Overall I t= hink this doc is good. A few nits:

o forEmailId: "String" Email Id of the= received email this MDN is relative to.

This needs to = be nullable, as described in MDN/parse.

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

I think th= is should be originalMessageId (lowercase d on the end) for = consistency.

2.1. MDN/set
Standard "/set" method as described in [RFC8620] where only the _create_ parameter is supported.
This is not quite right: the "accountId" and "ifInState" arg= uments are fine. I think this text should say something like:
<= div>
Only create is supported; a= ny attempt to update/destroy MUST be rejected with a "forbidden" SetErro= r.

And as a general comment, i= n the final versions of RFC8620/8621 we cleaned up the formatting so it = worked better in the plain text version of the RFCs; I suggest adopting = the same. So we use "quote" for a property name reference (not _undersco= re_) and remove the *asterisks* around the property names in the definit= ions.

Cheers,
Neil.
=
_______________________________________________
Jmap = mailing list
Jmap@ietf.org
https://www.ietf.= org/mailman/listinfo/jmap

--
Bron Gondwana, C= EO, Fastmail Pty Ltd
brong@fast= mailteam.com

--80eef5da27dd43788dd880e9d315b5fe-- From nobody Sat Nov 23 10:44:27 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 C840E12004F for ; Sat, 23 Nov 2019 10:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cketti.de 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 rCjo67S3qVcu for ; Sat, 23 Nov 2019 10:44:22 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (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 6295E120047 for ; Sat, 23 Nov 2019 10:44:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1574534659; s=strato-dkim-0002; d=cketti.de; h=In-Reply-To:Date:Message-ID:To:From:References:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=0IY7yx1hnxuz6JGlpbfpvKPEwxQUltUN27jtX2VtpZQ=; b=OvMrH6gK3tSw1r1phrImqN8U6pta55iQZDymeICf+MOnlkpbdtQ003fU47oaJay1V7 4fNYUNtYg646zx76iZBVPnylJtP8BrYZ+cR9OVgSPTq/++psj+Jg1Ab3pXGJUWZlbXVc DmAXIHaRWtdsxg6vqhsTMZnCxY0p4OYEN+6wDSMnSwyIoWpRGnhWDmhAYg2eQ5SY5ycU HaF0F0R1GaIVaDwcAAbqB6JNG1LFVc6UEbDnM8UjjtgPpLdQJQckSCvPlzR5sGxabxTd HdDVf2X6B4Xv+0XsYiwSZB3RFthaKnMZoGX+Zo2ky6BT1TKNdU22fyUJTc/ukpFw8VdC GO3w== X-RZG-AUTH: ":L2ckdkutb+sebmQwUUWXIIIYdHNZM+Bv5gC+3oIudZGrZypc/JzmdacuOGa/LyA0M07v/qat/O8ZrBG8CscRINnCHA==" X-RZG-CLASS-ID: mo00 Received: from [IPv6:2a02:2450:102b:ad9:a5bd:680:4c92:d6b0] by smtp.strato.de (RZmta 44.29.0 AUTH) with ESMTPSA id k0b9a3vANIiIvly (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sat, 23 Nov 2019 19:44:18 +0100 (CET) References: <1776898c-03ee-4d34-b254-a9c638dd3741@dogfood.fastmail.com> From: cketti Openpgp: preference=signencrypt Autocrypt: addr=ck@cketti.de; prefer-encrypt=mutual; keydata= mQINBE49+OsBEADIu2zVIYllkqLYaCZq2d8r80titzegJiXTaW8fRS0FKGE7KmNttWvWdiyL qvWlP4Py9OZPmEBdz8AaPxqCFmVZfJimf28CW0wz2sRCYmmbQqaHFfpDrK+EJofckOu2j81c oaFVLbvkvUNhWU7/DKyv4+EBFt9fjxptbfpNKttwI0aeUVCa+Z/m18+OLpeE33BXd5POrBb4 edAlMCwKk8m4nDXJ3B+KmR0qfCLB79gqEjsDLl+y65NcRk5uxIk53NRXHkmQujX1bsf5VFLh a4KbUaB7BCtcSi1rY99WXfO/PWzTelOhpKDIRq+v3Kl21TipY0t4kco4AUlIx5b1F0EHPpmI Dr0gEheZBali5c9wUR8czc/HaNkRP81hTPeBtUqp1S7GtJfcuWv6dyfBBVlnev98PCKOJo05 meVwf3hkOLrciTfo1yuy/9hF18u3GhL8HLrxMQksLhD6sPzDto4jJQDxKAa7v9aLoR7oIdeW kn1TU61EODR/254BRMoq619hqJwSNt6yOjGT2BBvlwbKdS8Xfw7SsBGGW8WnVJrqFCusfjSm DBdV/KWstRnOMqw4nhAwNFfXmAL2L8a+rLHxalFggfGcvVpzDhJyTg+/R1y3JMCoFfdFuhOT fkMqjGx8FgTmINOt54Wf9Xg6W0hQh3i98Wza3n8NuSPQJtAdqQARAQABtBVja2V0dGkgPGNr QGNrZXR0aS5kZT6JAkEEEwECACsCGyMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheA BQJOPftbAhkBAAoJEO4v7zp9qOKJG+oP/RBN5ahJCpwrk7U05J8x7UOPuP4UElMYoPYZCSp5 5mH6Xmr2C626DvTxhElz1WY7oIOJ7Mgp1RtGqZYV52d6fER10jowGbSkiFTvKb4PhQl4+AcG ODMYLRVBw90rRhDSXzBQMeiyUf7Wse1jPsBfuOe6V1TsAtqjaAzrUDQOcsjQqW5ezvIjGNTF unX6wMUHzSBX6Lh0fLAp5ICp+l3agJ8S41Y4tSuFVil2IRX3o4vqxvU4f0C+KDIeJriLAMHa jUp0V6VdisRHujjoTkZAGogJhNmNg0YH191a7AAKvVePgMQ/fsoW1hm9afwth/HOKvMx8fgK Mwkn004V/to7qHByWDND33rgwlv1LYuvumEFd/paIABhdLhC6o6moVzwlOqhGfoD8DZAIzNC S4q2uCg8ik4temetPbCc5wMFtd+FO+FOb1tO/RahWeBfULreEijnv/zUZPetkJV9jTZXgXqC I9GCf6MTJrOLZ+G3hVxFyyHTKlWtiIzJHlX9rd3oQc7YJbdDFMZA+SdlGqiGdsjBmq0kcRqh hEa5QsnoNm9tuPuFnL5oGG7OFPztj9tr9ViRvsFBlx9jvmjRbRNF3287j1r+4lbGigsA1o8b RkLLXVSK1gCwbOLAPNJYH5bde6O+Qb8bepg9TByiohsFssxYXHwbgu/pcCMU1hCf15t4uQIN BE49+OsBEACxJ8Ocv8y90ALoPcbh5LXVSgm8cAMvENXouVAPxkxp0y3bByDeXtQdmycmWmHD 0yE/sTYMz4cA0E6LBRaYPySz9cSNvJkoZPGot5bO9xISS1BmszmdLo8cjJFg9KyATHnumJED Bs1JCSmhLanlS3Iuu0PECxy3xN99Sck7XdIMJabOhQHez7gpf+dHGsq9MlzMeu4sCpMr12ix 2FI3StdzAtsaHOFa4q83zbV9CbQpgGKCdotmKu74C0GrFI281LC1LsIaJcqMcBOpQeqWgXU4 dXU2uJgjd2PIDPgjL3qkFHGbjshWQ1jbTDzwjXllkZCoH3Pn8B0ogh4Q1rv+0uv8Uqg296no F5unAANlhcSfqBME0kbyv/Pcuk96IhW45mbPrEkY62QLBN6wwtlhUVBQauv1e/njthdX6jSz 81zmlUF/YtwR7+F48QtD0KFRZ76UiZR0llbsOcQN0KmvBrgfNM1hKlQSd9IH6o9QQBK6SsGl SiTrr0bkGtsJKu4lzvyKOEu1EBxTvlPVvOz2jzXX48cRLFZnsXl4RfJec8B2MqiitD3If2A6 FJP/sOyZ93KZqXHopmFRA6/2Kq27y6WpB7hEIg4FmZnBxxFQOw237DlC6qtb56VatE4nLXWd tGfDCdoADD/RwmRz8S2nyN2KkK10d1CB2+PGcMvbXTL+zQARAQABiQIlBBgBAgAPBQJOPfjr AhsMBQkSzAMAAAoJEO4v7zp9qOKJBfgQAJDdCneNOBz8v9+ZggnVpuQx6XMRFEaGNV+pr+g/ qbz0B1DfRinmGE+sI3KbA7Ap9lF/ZqdHtuElzsWaFZSe0+i/0DfjFMJ7diwDvVwmSzIo4Xuy l+dRSY5XdVvV32rqoT5UdS86/XCSN1HYmHLGR91+kn1v4Sy0RDFpv92HwAlVVjZBvT2p4a6D XFa/duZP8ufFkSnSTjoDBhgWMiAL7Vm+ptEJ/e/ABOd6+5rB8GatOrD1yGSaQpegk3sjK6lP dBviSWNwXz/axbFPTi5A0a7ABC5XiPYlz0BsOiMXs3YvdwqmPmOMHgo7WMZv+byscLLIPwC1 ZDP1X7VoFkUp2Zp2cLm4Ac4MMsAcBh8Tx8+wld5QSmX8PFNy+DHd7tWzFLumPo1vt9tg/u/m Wi3SXo5piXBLy2iLXXOtCB0zPxm7Ve0w4qkGkZsi2OSsZ8Bi7YXGFLBiOx2AzahGtfnEXLQf JRFqYE4xyp8HprweXNXz8WqO8NeTtLb0gl9pA+VDKAG71iSb8XFEz0zwRB02FqwJPjcuwm3T APu9a/eNkV6PV3ZuIao3zHA13UJn437XxQda7AXeULovInXkD+8qZZbFgvHyVJFjet5XluYM rC8fTI+m7ulweK2Etcx9pHhrWXuEKpcbLOyT1bCcw/cUqLYPhv1m+xdxyx86XnqpMM1V To: jmap@ietf.org Message-ID: <69301983-f75d-ce20-4b63-b7a3e2b58e11@cketti.de> Date: Sat, 23 Nov 2019 19:44:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1776898c-03ee-4d34-b254-a9c638dd3741@dogfood.fastmail.com> Content-Type: multipart/alternative; boundary="------------725CA7DE59E73229B0113CD4" Content-Language: en-US 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: Sat, 23 Nov 2019 18:44:26 -0000 This is a multi-part message in MIME format. --------------725CA7DE59E73229B0113CD4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Capability > > 1.3. Addition to the capabilities object > > > > The capabilities object is returned as part of the standard JMAP > Session object; see the JMAP spec. Servers supporting _this_ > specification MUST add a property called "urn:ietf:params:jmap:mdn" > to the capabilities object. This could be more explicit and require the value to be an empty object, like it is for e.g. "urn:ietf:params:jmap:vacationresponse". But I think the capability should also be added to the "accountCapabilities" property of all accounts that support "MDN/set". I assume in most deployment scenarios this will only be the case for accounts that also have the "urn:ietf:params:jmap:submission" capability. The availability of "MDN/parse" can then be tied to the capability being present in "capabilities". The availability of "MDN/set" to the capability being present in "accountCapabilities" of the specific account. Text suggestion: > Capabilities are announced as part of the standard JMAP Session > resource; see [@!RFC8620], section 2. > > Support for the "MDN" data type and the "MDN/parse" method are > represented by the capability "urn:ietf:params:jmap:mdn" being present > in the "capabilities" property. > The capability "urn:ietf:params:jmap:mdn" being present in the > "accountCapabilities" property of an account represents support for > creating and sending MDN messages via the "MDN/set" method. > Servers that include the capability in one or more > "accountCapabilities" properties MUST also include the property in the > "capabilities" property. > > The value of this "urn:ietf:params:jmap:mdn" property is an empty > object in both the JMAP session "capabilities" property and an > account's "accountCapabilities" property. MDN/set and Email object modifications "EmailSubmission/set" can also modify referenced "Email" objects. RFC 8621 requires the method to include an "Email/set" response with the changes. It seems like a good idea to copy this mechanism for "MDN/set". Text suggestion (mostly copied from RFC 8621): > After all items in the "MDN/set" invocation have been processed, a > single implicit "Email/set" call MUST be made to set the "$MDNSent" > keyword on "Email" objects referenced by "MDN" objects that have been > successfully created. The response to this MUST be returned after the > "MDN/set" response. Minor issues > o *forEmailId*: "String" Email Id of the received email this MDN is > relative to. Expanding on the comment from Neil, the type should be "Id|null". > The Email/parse method takes the following arguments: > > o *accountId*: "String" The id of the account to use. This should be "MDN/parse method" and the type for "accountId" should be "Id". Best, cketti --------------725CA7DE59E73229B0113CD4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Capability

1.3. Addition to the capabilities object
The capabilities object is returned as part of the standard JMAP Session object; see the JMAP spec. Servers supporting _this_ specification MUST add a property called "urn:ietf:params:jmap:mdn" to the capabilities object.

This could be more explicit and require the value to be an empty object, like it is for e.g. "urn:ietf:params:jmap:vacationresponse".

But I think the capability should also be added to the "accountCapabilities" property of all accounts that support "MDN/set". I assume in most deployment scenarios this will only be the case for accounts that also have the "urn:ietf:params:jmap:submission" capability.
The availability of "MDN/parse" can then be tied to the capability being present in "capabilities". The availability of "MDN/set" to the capability being present in "accountCapabilities" of the specific account.

Text suggestion:

Capabilities are announced as part of the standard JMAP Session resource; see [@!RFC8620], section 2.

Support for the "MDN" data type and the "MDN/parse" method are represented by the capability "urn:ietf:params:jmap:mdn" being present in the "capabilities" property.
The capability "urn:ietf:params:jmap:mdn" being present in the "accountCapabilities" property of an account represents support for creating and sending MDN messages via the "MDN/set" method.
Servers that include the capability in one or more "accountCapabilities" properties MUST also include the property in the "capabilities" property.

The value of this "urn:ietf:params:jmap:mdn" property is an empty object in both the JMAP session "capabilities" property and an account's "accountCapabilities" property.

MDN/set and Email object modifications

"EmailSubmission/set" can also modify referenced "Email" objects. RFC 8621 requires the method to include an "Email/set" response with the changes. It seems like a good idea to copy this mechanism for "MDN/set".

Text suggestion (mostly copied from RFC 8621):

After all items in the "MDN/set" invocation have been processed, a single implicit "Email/set" call MUST be made to set the "$MDNSent" keyword on "Email" objects referenced by "MDN" objects that have been successfully created. The response to this MUST be returned after the "MDN/set" response.

Minor issues

o *forEmailId*: "String" Email Id of the received email this MDN is relative to.

Expanding on the comment from Neil, the type should be "Id|null".

The Email/parse method takes the following arguments: o *accountId*: "String" The id of the account to use.

This should be "MDN/parse method" and the type for "accountId" should be "Id".

Best,
cketti

--------------725CA7DE59E73229B0113CD4-- From nobody Mon Nov 25 13:11:59 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 ADA641200B7; Mon, 25 Nov 2019 13:11:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jim Fenton via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Cc: fenton@bluepopcorn.net, jmap@ietf.org, iesg-secretary@ietf.org, jmap-chairs@ietf.org, Jim Fenton Message-ID: <157471631770.13972.2081848894923306327.idtracker@ietfa.amsl.com> Date: Mon, 25 Nov 2019 13:11:57 -0800 Archived-At: Subject: [Jmap] Publication has been requested for 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: Mon, 25 Nov 2019 21:11:58 -0000 Jim Fenton has requested publication of draft-ietf-jmap-websocket-04 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-websocket/