Re: [Jmap] Feedback on the quota draft

["Bron Gondwana" <[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]