Re: [Jmap] Feedback on the quota draft

[René CORDIER <[e-mail]>]

That should do it, thank you Bron !

Cheers,

Rene.

Le 17 janvier 2020 14:52, de [e-mail]

Hi Rene,

IETF107 in Vancouver is 21-17 March.

Cheers,

Bron.

On Fri, Jan 17, 2020, at 18:31, René CORDIER wrote:

Hi Bron,

I've been lacking time unfortunately lately to rework on this, but it's still in the back of my mind. I should be able to give it more thoughts on it and rework it soon. When is your meeting in Vancouver?

Apologies regarding the delay !

Cheers,

Rene.

Le 17 janvier 2020 11:54, de [e-mail]

Following up on this thread - there's been a bunch of feedback on the last draft.  Can you please produce a new draft incorporating the feedback so we can discuss it again.  I'd like to have this document in a condition to have a productive discussion in Vancouver.

Thanks,

Bron.

On Thu, Nov 21, 2019, at 22:11, René CORDIER wrote:

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 about it. I will try to do better in the future !

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

Cheers,

Rene.

Le 20 novembre 2019 18:20, de [e-mail]

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": "[e-mail]",
     "datatypes" : [ "Mail", "Calendar", "Contact", "Todo" ],

}

And this would be displayed in a a box called "Quota Use":

[e-mail] 52%

Something like that :)

Cheers,

Bron.

--

  Bron Gondwana, CEO, Fastmail Pty Ltd

  [e-mail]

_______________________________________________

Jmap mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/jmap

--

  Bron Gondwana, CEO, Fastmail Pty Ltd

  [e-mail]

_______________________________________________

Jmap mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/jmap

--

  Bron Gondwana, CEO, Fastmail Pty Ltd

  [e-mail]