Re: [Jmap] Feedback on the quota draft

[Bron Gondwana <[e-mail]>]

Hi René,

Thanks for updating the draft! I'm about to hop on a plane and then I'll be on holiday for a couple of weeks - so just brief responses now! I've flagged this message to get back to when I'm working again.

Responses inline.

On Wed, Mar 4, 2020, at 17:41, René CORDIER wrote:
> Hi all,

> First of all, I would like to apologize for the time spent on this. I will try to fix comments faster in the future.

> Then, I am happy to say that I finally released the new draft version of JMAP quotas specs. Please have a look at the ietf tracker: https://datatracker.ietf.org/doc/draft-ietf-jmap-quotas

> I also did a github PR with the code change: https://github.com/jmapio/jmap/pull/318

> I tried to answer inline below as well to the feedback mashup generously made by Bron last time. Please don't hesitate to have a look.

> I would like to add an extra note as well, regarding the "quotaIds", it made little sense to add a field in "Mailbox" object indeed. I moved it as a property of the additional account's capability "urn::ietf::params::jmap::quota", as I think it makes more sense to have the quotas bounded to the account.

> I would like to discuss an other idea as well (that is not represented in this draft). Some properties seem likely to be repeated many times. I thought of adding a new Object for that, called "QuotaResource", that would be defined by a "name", "resourceType", "warnLimit", "softLimit", "limit" and "scope". Probably we want those to be the same for a group of users or all users, repeating it for each Quota sounds redundant? Something like that:


> "QuotaResource": {
>  "id": "re01",
>  "name": "normal user quota resource",
>  "resourceType": "count",
>  "warnLimit": 1600,
>  "softLimit": 1800,
>  "limit": 2000,
>  "scope": "account"
> }


> "Quota": {
>  "id": "qu01",
>  "quotaResourceId": "re01",
>  "used": 1056,
>  "name": "[e-mail]",
>  "description": "Personal account usage",
>  "datatypes": [ "Mail", "Calendar" ]
> }

> With maybe methods like /get, /set, /query ?

> Do you feel like it could be a good idea? Or does it make the all thing too complex and unnecessary?


I think it's probably too complex - but maybe others disagree. I don't feel super strongly about it so long as there's clear guidance on how to use it.

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

> 
> Agreed, one scope is simpler and more logical.

>> 
>> *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, ...).

> 
> I liked that idea. Allows to apply Quota to more than just mails, so to other defined jmap objects defined by the specs, or even custom server ones.

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

> 
> I did add the "/query", and also the "/queryChanges". I don't have a strong opinion on this but maybe it can be useful for a server to have "/queryChanges" too.

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

> 
> I agree that "used" is probably gonna changed a lot compared to other fields, and that we are probably most interested by this field on a regular basis. 

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

> 
> +1

>> 
>> *Description*
>> 
>> Do we need to provide for both a short "name" and a longer "description" field on each quota?

> 
> +1

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

> 
> +1

>> 
>> *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?

> 
> I would agree to Neil's comment on that one, that suggested that if we have the "datatypes" property, then we just need to have types like "count" or "size". Then for the "what do we count or calculate the size of?" question, the answer would be in the declared data types. 

> Regarding the size, I put it in bytes by default, but still precised that it's up to the server to choose (maybe some server wants octets?). But that might be confusing for the client... Or should we have more granular resource types here, like "bytes" and "octets", or "sizeBytes" and "sizeOctets"?


Bytes and Octets are the same thing, to a reasonable approximation:

https://en.wikipedia.org/wiki/Octet_(computing)

Byte has historically been used for other sizes, but it always means 8 bits these days.

I see no reason to allow any other unit - if we're doing 64 bit values there's plenty of room, and unit conversions at the low level suck and are grounds for confusion.

Bron.

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [e-mail]