[Jmap] Feedback on the quota draft

"Bron Gondwana" <brong@fastmailteam.com> Wed, 20 November 2019 11:21 UTC

Return-Path: <brong@fastmailteam.com>
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 <jmap@ietfa.amsl.com>; 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 <jmap@ietfa.amsl.com>; 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 <jmap@ietf.org>; 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: <xms:yCHVXWk7Kp47GlvalVSlFDxhbu3AgUrmXGYuFLDKs-FqVs27TdFbWQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehtddgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhhonhcu ifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomheqne curfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdr tghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:yCHVXe7Cig3_MM1thJBE2AkhlCDoHXQgsIoChw4QyF6Ypgvicw9o_w> <xmx:yCHVXcLwYvhZrhWm1M132_zTR-BtjE5d0EygACOHsMMXd-bY-KPBFg> <xmx:yCHVXY2sNOwHufleVsCjp-XX_k2SSjvsEhWuZDsciIuIS-m0lpalwA> <xmx:ySHVXWEFOBSIrw8pg8R5lETOdUTn9aERRivVfb9Pfz8pHyvht3WILw>
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: <cb566662-c4cd-46b8-83db-170c9c91f19f@dogfood.fastmail.com>
Date: Wed, 20 Nov 2019 22:20:58 +1100
From: Bron Gondwana <brong@fastmailteam.com>
To: jmap@ietf.org
Cc: René CORDIER <rcordier@linagora.com>, Michael BAILLY <mbailly@linagora.com>
Content-Type: multipart/alternative; boundary="47d9b4a06dbb40d69680b348fa416ed4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/C_qFtcA4nUIsr-GYWK5xXPpGPxw>
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 <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2019 11:21:48 -0000

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