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

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 07 Feb 2022 14:16:28 +1100

Hi,

Sorry this feedback is very delayed! The general shape of this looks good, but I have a few comments:

   The value of this property in an account's accountCapabilities
   property is an object that MUST contain the following information on
   server capabilities and permissions for that account:

   *  *quotaIds:* "Id[]" (default: "[]") A list of quota ids bound to
      that account, or "[]" if that account has no quota restrictions.

I'm not sure why we need to return quota ids in the account capabilities here? We can just fetch all with Quota/get and putting data in the session object is awkward when it's not immutable.

1.4.1.  Scope

   The *Scope* is a "String" from an enumeration defined list of values,
   handled by the server.

   It explains the entities this value applies to.  Some custom
   specifications might provide some additional values.  If the client
   does not specify custom scope specifications in the "using" parameter
   of the request, the server should respond the JSON value "null",
   instead of answering a scope value that the client does not support.
   Standard values are:

Extensibility is always tricky! My first thought is does this need to be extensible? And secondly, if it does not to be extendable, how useful are quotas with a scope the client can't understand? The server can always return an `overQuota` error for something regardless of these objects; they are really just to display to the user. In which case, we don't need to define extensibility here: any custom extension can just specify that Quota objects making use of the extension should only be exposed if the extension is opted-into (i.e. you just don't return anything that's using a custom scope if you're only using the standard capability), which simplifies this spec.

The same applies to `ResourceType`.

   *  "size": The quota is measured in size (in "bytes").  For example,
      a quota can have a limit of 25000 "bytes".

I suggest this be called "octets" rather than "size"; it's clearer what is being limited ("size" is a bit ambiguous).

   *  *limit*: "UnsignedInt" The hard limit set by this quota object.
      No more outgoing and ingoing objects should be allowed if we reach
      this limit.

I'm not sure exactly what's meant by "outgoing" and "ingoing" objects. Should this be something like: "Objects in scope may not be created or updated if we reach this limit."?

Cheers,
Neil.

---

From: Rene Cordier <[email-masked]>
Date: Tue, 8 Feb 2022 10:16:52 +0700

Hi Neil,

Thanks for the feedback! Even if delayed it's still appreciated and 
valuable! I agree with your comments and will apply them.

Cheers,
Rene.

On 07/02/2022 10:16, Neil Jenkins wrote:
> I'm not sure why we need to return quota ids in the account capabilities 
> here? We can just fetch all with Quota/get and putting data in the 
> session object is awkward when it's not immutable.
> 
> 1.4.1.  Scope
> 
> Extensibility is always tricky! My first thought is does this need to be 
> extensible? And secondly, if it does not to be extendable, how useful 
> are quotas with a scope the client can't understand? The server can 
> always return an |overQuota| error for something regardless of these 
> objects; they are really just to display to the user. In which case, we 
> don't need to define extensibility here: any custom extension can just 
> specify that Quota objects making use of the extension should only be 
> exposed if the extension is opted-into (i.e. you just don't return 
> anything that's using a custom scope if you're only using the standard 
> capability), which simplifies this spec.
> 
> The same applies to |ResourceType|.
> 
> I suggest this be called "octets" rather than "size"; it's clearer what 
> is being limited ("size" is a bit ambiguous).
> 
> I'm not sure exactly what's meant by "outgoing" and "ingoing" objects. 
> Should this be something like: "Objects in scope may not be created or 
> updated if we reach this limit."?
> 
> Cheers,
> Neil.
> 
> _______________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap

---

From: Benoit TELLIER <[email-masked]>
Date: Mon, 7 Feb 2022 10:25:23 +0700

Hi,

Answers inlined.

Happy to see this moving.

Best regards,

Benoit TELLIER

On 07/02/2022 10:16, Neil Jenkins wrote:
> I'm not sure why we need to return quota ids in the account 
> capabilities here? We can just fetch all with Quota/get and putting 
> data in the session object is awkward when it's not immutable.
>
> 1.4.1.  Scope
>
> Extensibility is always tricky! My first thought is does this need to 
> be extensible? And secondly, if it does not to be extendable, how 
> useful are quotas with a scope the client can't understand? The server 
> can always return an |overQuota| error for something regardless of 
> these objects; they are really just to display to the user. In which 
> case, we don't need to define extensibility here: any custom extension 
> can just specify that Quota objects making use of the extension should 
> only be exposed if the extension is opted-into (i.e. you just don't 
> return anything that's using a custom scope if you're only using the 
> standard capability), which simplifies this spec.
>
+1 this was likely over designed and represent a divergence with the 
original IMAP spec.

Reaching a consensus on this or its usefulness might be hard; we likely 
should rather drop it.
> I suggest this be called "octets" rather than "size"; it's clearer 
> what is being limited ("size" is a bit ambiguous).
'size' is an explicit property of the Email entity.

Though I am fine with octet if this is consensual.
> updated if we reach this limit."?
+1 (this would make sense if you substitute "Email" to "Object")