Subject: [Jmap] Feedback on the quota draft

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 20 Nov 2019 22:20:58 +1100

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": "[email-masked]",
     "datatypes" : [ "Mail", "Calendar", "Contact", "Todo" ],
}

And this would be displayed in a a box called "Quota Use":
[email-masked] 52%

Something like that :)

Cheers,

Bron.*
*
--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 20 Nov 2019 22:24:33 +1100

> 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.

---

From: "Neil Jenkins" <[email-masked]>
Date: Thu, 21 Nov 2019 20:44:19 +0800

On Wed, 20 Nov 2019, at 19:20, Bron Gondwana wrote:
> *Resource Types*

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.