From nobody Thu Feb 3 21:06:21 2022 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C773A1EA0; Thu, 3 Feb 2022 21:06:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <164395117423.11999.16253056366797448896@ietfa.amsl.com> Date: Thu, 03 Feb 2022 21:06:14 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-calendars-07.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2022 05:06:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Calendars Authors : Neil Jenkins Michael Douglass Filename : draft-ietf-jmap-calendars-07.txt Pages : 45 Date : 2022-02-03 Abstract: This document specifies a data model for synchronizing calendar data with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-jmap-calendars-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-calendars-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sun Feb 6 18:23:14 2022 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9473A11FF; Sun, 6 Feb 2022 18:23:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <164420058046.32551.10908506908885692977@ietfa.amsl.com> Date: Sun, 06 Feb 2022 18:23:00 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-sharing-01.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2022 02:23:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP Sharing Author : Neil Jenkins Filename : draft-ietf-jmap-sharing-01.txt Pages : 11 Date : 2022-02-06 Abstract: This document specifies a data model for sharing data between users using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-sharing/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-jmap-sharing-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-sharing-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sun Feb 6 19:17:10 2022 Return-Path: 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 ; 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 ; 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 ; 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 ; 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrheeggdehvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepvedvtedvudelkefhgefhteeftedtlefhheefveffveelkedu tdduffeiveejvefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: 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: References: <162979023587.19029.15509717875037771799@ietfa.amsl.com> Date: Mon, 07 Feb 2022 14:16:28 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=db5ec82aeea8426194bebca8f9bb716b Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2022 03:17:09 -0000 --db5ec82aeea8426194bebca8f9bb716b Content-Type: text/plain 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. --db5ec82aeea8426194bebca8f9bb716b Content-Type: text/html Content-Transfer-Encoding: quoted-printable
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 immutabl= e.

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 t= hought 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 un= derstand? The server can always return an overQuota error for something regardless of these objects; they are really ju= st to display to the user. In which case, we don't need to define extens= ibility here: any custom extension can just specify that Quota objects m= aking use of the extension should only be exposed if the extension is op= ted-into (i.e. you just don't return anything that's using a custom scop= e if you're only using the standard capability), which simplifies this s= pec.

The same applies to = ResourceType.

   *  "size": The quota is measured in s=
ize (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).

   *  *li=
mit*: "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 l= ike: "Objects in scope may not be created or updated if we reach this li= mit."?

Cheers,
Neil.
--db5ec82aeea8426194bebca8f9bb716b-- From nobody Mon Feb 7 19:17:05 2022 Return-Path: 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 17D953A11C2 for ; Mon, 7 Feb 2022 19:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.613 X-Spam-Level: X-Spam-Status: No, score=-7.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 txPhkW3nZVRP for ; Mon, 7 Feb 2022 19:16:59 -0800 (PST) Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C06A3A11C0 for ; Mon, 7 Feb 2022 19:16:57 -0800 (PST) Received: from [192.168.10.109] (unknown [123.16.38.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id 67AE3416AA for ; Tue, 8 Feb 2022 04:16:54 +0100 (CET) Message-ID: Date: Tue, 8 Feb 2022 10:16:52 +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> <2edd4357-c88e-4041-bc01-3d6b72d446b3@beta.fastmail.com> X-LINAGORA-Copy-Delivery-Done: 1 From: Rene Cordier In-Reply-To: <2edd4357-c88e-4041-bc01-3d6b72d446b3@beta.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2022 03:17:04 -0000 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: > 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. > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Mon Feb 7 23:27:31 2022 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 148653A09A6; Mon, 7 Feb 2022 23:27:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <164430524800.14618.9409963768854711572@ietfa.amsl.com> Date: Mon, 07 Feb 2022 23:27:28 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-quotas-03.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2022 07:27:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Quotas Author : René Cordier Filename : draft-ietf-jmap-quotas-03.txt Pages : 9 Date : 2022-02-07 Abstract: This document specifies a data model for handling quotas on accounts with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-quotas/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-jmap-quotas-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-quotas-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Feb 8 18:39:38 2022 Return-Path: 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 D57393A0736 for ; Tue, 8 Feb 2022 18:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=rvUBORHu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fKv4RTfU 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 8_UgqVYOF6jv for ; Tue, 8 Feb 2022 18:39:30 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC4E3A0653 for ; Tue, 8 Feb 2022 18:39:29 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id EC0AB32020D9 for ; Tue, 8 Feb 2022 21:39:28 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute4.internal (MEProxy); Tue, 08 Feb 2022 21:39:29 -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=tAXH5y3EWuxJ49 Y9JIzc7fwGnK6dUt/tNxY6R58Efuo=; b=rvUBORHub6Sb5WgO+DvfHnC3oBJ/Bf 8J5O8pgBlA6m8A3RT3QzkaEaet7N+bgVbM3LuIfY3/af6JNpOwiGMBbfQK3tAkGI UqjsGcVE/j6O5EvGFvWq0ctbo0r1S9VOCEaDmPKY1PGpmqWWBb+wsTxKPS6vYuNH Qk2o2LqnM67PHMB+3V01lwM5HoCRJFlGvfzPhIIjhBEeyERsGAx8T+2RjcoHgHiZ wupZPevCaiM83E+hCPlplHJ/AuU/T8IeTE81r0xr5WnszYHXCV8J0kuBh8fjmolI KibmA4LNpyB/1CTcG5feJEfrmtOPduMfMeALRq98D+MSh8hfGkSWdZww== 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=tAXH5y3EWuxJ49Y9J Izc7fwGnK6dUt/tNxY6R58Efuo=; b=fKv4RTfUG3lQHzQ84AmAQWBJHqBBVWTb3 gHdSvGQXh4qvWuLSkGpn89YIgVrdVybFfwcGrjUPkVVHJ2Z4jpI6Aw/dIa3+pKVm ZCrPnL3YznT8V6/eYD1RVxtYvEGiiVQuzQIuDSlNYxl+t7TEEfORTEjIY5KVoEhZ T2nW2SHih2ETVN+HeGpmXx0Tu/40V3JLS9G/xY3IGosD6TkHCsvFwXLxZEQa74Cs QWLqNAuE/dqYi1Ma0NLfhPLvhJRJFHYLKYsaKISRwgjJBeeavy0xCQQnXUYEEddC HEXAaPTlvd3Ythm5cr0IL7+5xqfcqamS2lypGMyvyzr1juOC86kmA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrheekgdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepvedvtedvudelkefhgefhteeftedtlefhheefveffveelkedu tdduffeiveejvefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4392DAC0E99; Tue, 8 Feb 2022 21:39:28 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4748-g31a5b5f50e-fm-cal2020-20220204.001-g31a5b5f5 Mime-Version: 1.0 Message-Id: <7780acf7-66c4-4264-a2e3-69e2e6a324dd@qa.fastmail.com> In-Reply-To: References: <163636948717.1974.2518230128440392785@ietfa.amsl.com> Date: Wed, 09 Feb 2022 13:39:07 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=0e6bb9ce2a09478bb8e6d7f8f8d9ab20 Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-smime-sender-extensions-01.txt X-BeenThere: jmap@ietf.org 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: Wed, 09 Feb 2022 02:39:36 -0000 --0e6bb9ce2a09478bb8e6d7f8f8d9ab20 Content-Type: text/plain I've had a look through this, and it looks reasonable to me but I'd like to see definition for what errors the server will return in case of failures. You probably want to define some explicit new error types for the scenarios (e.g. couldn't find private key/cert and a list of the destination addresses for which this was the case so the client can show the user what the problem is). Cheers, Neil --0e6bb9ce2a09478bb8e6d7f8f8d9ab20 Content-Type: text/html
I've had a look through this, and it looks reasonable to me but I'd like to see definition for what errors the server will return in case of failures. You probably want to define some explicit new error types for the scenarios (e.g. couldn't find private key/cert and a list of the destination addresses for which this was the case so the client can show the user what the problem is).

Cheers,
Neil
--0e6bb9ce2a09478bb8e6d7f8f8d9ab20-- From btellier@apache.org Sun Feb 6 19:25:50 2022 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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> <2edd4357-c88e-4041-bc01-3d6b72d446b3@beta.fastmail.com> From: Benoit TELLIER In-Reply-To: <2edd4357-c88e-4041-bc01-3d6b72d446b3@beta.fastmail.com> 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-BeenThere: jmap@ietf.org 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 This is a multi-part message in MIME format. --------------NCy2Lm47P0pHljIJOHYY6j0Q Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------NCy2Lm47P0pHljIJOHYY6j0Q Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

Answers inlined.

Happy to see this moving.

Best regards,

Benoit TELLIER

On 07/02/2022 10:16, Neil Jenkins wrote: