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

Neil Jenkins <neilj@fastmailteam.com> Mon, 07 February 2022 03:17 UTC

Return-Path: <neilj@fastmailteam.com>
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 34F4F3A12C4 for <jmap@ietfa.amsl.com>; Sun, 6 Feb 2022 19:17:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ZlNQSV74; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Zdw2M9IV
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 A2DwMAkRE0Ju for <jmap@ietfa.amsl.com>; Sun, 6 Feb 2022 19:17:02 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8FE3A12CF for <jmap@ietf.org>; Sun, 6 Feb 2022 19:16:53 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 9B01E320093A for <jmap@ietf.org>; Sun, 6 Feb 2022 22:16:49 -0500 (EST)
Received: from imap43 ([10.202.2.93]) by compute4.internal (MEProxy); Sun, 06 Feb 2022 22:16:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; bh=BdEdaRq64qGQOA ed74VR+ouKag+W4FC1LgE1MMsEYCo=; b=ZlNQSV74iRQTBi5o5uGzuWaWrRGAR/ KWA8atIC0xAb+s5UEHJFKnGSXwo2EKj6CW/BjgOl1sUYoTAnmMUXZK+sjz26QoHq Nad5fwIJ93BvoxU3i+5CcdgDH7V6i3Hcv4EmXY+4abK9qj83STHXFR2S0Qx59Hcz dx7DiizoIdBvQbSNYyJ4r+bjJ2aFZkaTRn33BPuVXKX1h41o37J43P70KWEsQ2Zb d0SI6/R1DX++IRJpSShuPaeH+u2KIPH4TjH/iU5xcgU0zzXwy6oa2CHqki28JmWV byp36D1uztv2LMwl5WoBTp29b3o5U7yIfe3u0pUMZogNXOY6g1ZVgKwA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=BdEdaRq64qGQOAed7 4VR+ouKag+W4FC1LgE1MMsEYCo=; b=Zdw2M9IVjOmHsZv5IKj8dzc6GaRcG3gXM 8S2ozHpLStUb8add82IDzPe6ufHQgPr9GZ4VE3gz21AzFAci7iNkxgJeRbolaVnq zpMAccCJrO0OH8g1Cv9GWTsjeMpFKoacuovHlJNwydR47IEUSUfuiI9Gw4t34Vur U01zf8IyYq+yp29893KJtglYFD/vJfsXrFdZ44NQTHn+8qyChE0OxSfi3WWjnToi pbj/TsShEFN/QOKGwbt7+CNwkBWbz0ax6CQ5EqvBGYaWMvKUPfzHWAl9mykOtyMW wJjo/7gm6Z7AagX0O03oS9LPv/GC4CcDuHHK6pG34bAnM/KvJg5uQ==
X-ME-Sender: <xms:IY8AYkRMPlaS4OaTLEfXVMWHIsItkpZdGtOHKfbke403cS9lgthO6A> <xme:IY8AYhytsT9oRRPdwEHOjrY8CHHZ8rkh_euN6H1WPYPXUmJX2RLoWhIO391wacjZh 6oVG4fkv8bqow>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrheeggdehvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepvedvtedvudelkefhgefhteeftedtlefhheefveffveelkedu tdduffeiveejvefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy: <xmx:IY8AYh01XpXgwuikENKxaU0Z_RLbeTlQCfosw7liRuTM8e6CJZfP2w> <xmx:IY8AYoAXdJ4Sx1Tp8ycDdCCmtd-g5Tls0ZH5ur4X2g2U8hltZRkB9A> <xmx:IY8AYtjFzqorYX5hXGECll7QzfFUsVzV8adpq9UphHvg2W4P8pOAVw> <xmx:IY8AYot7ip21965QFt44XzJl1Bk3OgvoLJia0BgpgrnYopNJ4uT_lQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 01FCEAC0E99; Sun, 6 Feb 2022 22:16:49 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4745-gf9b5b8e72a-fm-cal2020-20220203.002-gf9b5b8e7
Mime-Version: 1.0
Message-Id: <2edd4357-c88e-4041-bc01-3d6b72d446b3@beta.fastmail.com>
In-Reply-To: <Mime4j.530.d78e690a7d9100f9.17b77143f72@linagora.com>
References: <162979023587.19029.15509717875037771799@ietfa.amsl.com> <Mime4j.530.d78e690a7d9100f9.17b77143f72@linagora.com>
Date: Mon, 07 Feb 2022 14:16:28 +1100
From: Neil Jenkins <neilj@fastmailteam.com>
To: IETF JMAP Mailing List <jmap@ietf.org>
Content-Type: multipart/alternative; boundary="db5ec82aeea8426194bebca8f9bb716b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/w1iEHg1HFdTOgu49MuR74kC_SG8>
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:17:09 -0000

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.