Re: [Jmap] I-D Action: draft-ietf-jmap-quotas-00.txt

[Benoît TELLIER <[e-mail]>]

Hi Neil,

Le 29 octobre 2019 12:20, de [e-mail]

Some feedback on this draft:

• It's mail-specific at the moment, but could probably be made pretty generic, which I think would be more useful. e.g. Instead of "mesageCount" and "mesageStorageSize" we'd just have "size" or "count" as the types of quota, which could apply to any object type. Then you have another property on the Quota object that lists the data type(s) it applies to.

+1

• I'm a bit unclear on how "usedScope" and "limitScope" could be different and what this would mean in practice (and if this is actually done in the real world).

For instance imagine that I define that users of my email server will not store more than 2 GB of data

Bobs stores 1 GB of mail in his mailboxes thus have a 50% size quota. The upper bound is the generic limit user on this mailserver has. (limitSope is "global" , usedScope "personal")

Alice asked for a 10 GB quota upper bound, specififc to her. Given that she has 1 GB email, she has 10% size quota (limitSope is "personal" , usedScope "personal")

Imagine now that a mail provider proposes cold storage for achived mailbox.  It could be interesting to expose two quota on an account: (limitSope: personal , usedScope :personal) & (limitSope: personal/archive , usedScope :personal/archive) (JMAP custom vendor extension)
 - The client supporting the extension will be able to correctly contextualize both quota, and display correct explanation in a UI
 - The not aware client will  be able to recognise "the default quota" that applies for the account, and will be able to explein that another quota applies, though the exact definition of it is unknown.

Another example where it could be useful is if I have a cloud provider email subscription for a enterprise. We can imagine offers like "1TB company wide, define user quota as you wish".

As far as I understand it, IMAP quota RFC limit itself to expressing the limitation. There is no explanation of the "why" behind it despite potentially complex combination possibilities. I have no idea if this is a problem, and thus if it should be addressed though.

• I'm not sure I see the purpose of the "quotaIds" property addition to the Mailbox object. I feel it would be cleaner not to add this (but add a property to the Quota object to indicate a subscope if it only applies to a subset of the objects of that type in the account).

Why would it be cleaner?

From a client perspective, I can back reference the quotaIds after a mailboxes/get call, which is easy to implement.

While if I have a quota that lists entities it applies to I got a quota object change every time a new entity aplies this quota. Is this desirable or useful?

Cheers,

Neil.

Cheers,

Benoit