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

Benoit TELLIER <btellier@apache.org> Mon, 07 February 2022 03:25 UTC

Return-Path: <btellier@apache.org>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6EB3A12D3 for <jmap@ietfa.amsl.com>; Sun, 6 Feb 2022 19:25:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.612
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5-POyY4wVbI for <jmap@ietfa.amsl.com>; Sun, 6 Feb 2022 19:25:45 -0800 (PST)
Received: from mxout1-ec2-va.apache.org (mxout1-ec2-va.apache.org [3.227.148.255]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D2C3A12CA for <jmap@ietf.org>; Sun, 6 Feb 2022 19:25:45 -0800 (PST)
Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153]) by mxout1-ec2-va.apache.org (ASF Mail Server at mxout1-ec2-va.apache.org) with SMTP id 7B8183E952 for <jmap@ietf.org>; 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 mailrelay1-he-de.apache.org (HELO mailrelay1-he-de.apache.org) (116.203.21.61) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Feb 2022 03:25:44 +0000
Received: from [192.168.0.103] (unknown [1.55.250.122]) by mailrelay1-he-de.apache.org (ASF Mail Server at mailrelay1-he-de.apache.org) with ESMTPSA id DDF383E847 for <jmap@ietf.org>; Mon, 7 Feb 2022 03:25:42 +0000 (UTC)
Content-Type: multipart/alternative; boundary="------------NCy2Lm47P0pHljIJOHYY6j0Q"
Message-ID: <8f6d539f-0ddd-50ac-7b67-75adb153fb6f@apache.org>
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
To: jmap@ietf.org
References: <162979023587.19029.15509717875037771799@ietfa.amsl.com> <Mime4j.530.d78e690a7d9100f9.17b77143f72@linagora.com> <2edd4357-c88e-4041-bc01-3d6b72d446b3@beta.fastmail.com>
From: Benoit TELLIER <btellier@apache.org>
In-Reply-To: <2edd4357-c88e-4041-bc01-3d6b72d446b3@beta.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/YoyOrvqQkI7ECCtfub3BY8DT6e8>
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-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2022 03:29:30 -0000

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
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap