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

Benoit TELLIER <> Mon, 07 February 2022 03:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E6EB3A12D3 for <>; Sun, 6 Feb 2022 19:25:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.612
X-Spam-Status: No, score=-10.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c5-POyY4wVbI for <>; Sun, 6 Feb 2022 19:25:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61D2C3A12CA for <>; Sun, 6 Feb 2022 19:25:45 -0800 (PST)
Received: from ( []) by (ASF Mail Server at with SMTP id 7B8183E952 for <>; Mon, 7 Feb 2022 03:25:44 +0000 (UTC)
Received: (qmail 40810 invoked by uid 99); 7 Feb 2022 03:25:44 -0000
Received: from (HELO ( by (qpsmtpd/0.29) with ESMTP; Mon, 07 Feb 2022 03:25:44 +0000
Received: from [] (unknown []) by (ASF Mail Server at with ESMTPSA id DDF383E847 for <>; Mon, 7 Feb 2022 03:25:42 +0000 (UTC)
Content-Type: multipart/alternative; boundary="------------NCy2Lm47P0pHljIJOHYY6j0Q"
Message-ID: <>
Date: Mon, 7 Feb 2022 10:25:23 +0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
References: <> <> <>
From: Benoit TELLIER <>
In-Reply-To: <>
Archived-At: <>
X-Mailman-Approved-At: Mon, 14 Feb 2022 13:51:16 -0800
Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-quotas-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Feb 2022 03:29:30 -0000


Answers inlined.

Happy to see this moving.

Best regards,


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