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

[Benoit TELLIER <[e-mail]>]

Hi,

Answers inlined.

Happy to see this moving.

Best regards,

Benoit TELLIER

On 07/02/2022 10:16, Neil Jenkins wrote:
> 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|.
+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.
>
>     *  "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).
'size' is an explicit property of the Email entity.

Though I am fine with octet if this is consensual.
>
>     *  *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."?
+1 (this would make sense if you substitute "Email" to "Object")
>
> Cheers,
> Neil.
>
> _______________________________________________
> Jmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jmap