Re: [Jmap] Paul Wouters' Discuss on draft-ietf-jmap-quotas-10: (with DISCUSS)

rcordier@linagora.com Tue, 31 January 2023 07:45 UTC

Return-Path: <rcordier@linagora.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 B3BBDC14F726; Mon, 30 Jan 2023 23:45:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level:
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=linagora.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUGRh0KPmEjD; Mon, 30 Jan 2023 23:45:09 -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 155A2C14F6EC; Mon, 30 Jan 2023 23:45:08 -0800 (PST)
Received: from ?Open?PaaS?SMTP?server?for?Linagora? (unknown [51.83.109.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id F33BF3EE62; Tue, 31 Jan 2023 08:45:05 +0100 (CET)
DKIM-Signature: a=rsa-sha256; b=c1+s0rbSTSZY9VyIy0m/r8ZZOHEOa3cDUUsQ8bfY7k7YB4LSiT4dYh4FZY7sV1AuxkKfzrdcc2eCxHLYZ2uz+UjLpTZxZUu8aziYfXAsjNmu4zWNmvXgd+BbFCmopaw+nLSaavqCa0AvmproiesnMSPyGyQ2gIc8DI9jMcC58o0NFRZ7huqlFOR3yhnhe3k17EG7oKYgzxjKTjp3iFZTLL0gVITF1q2mUcSdUGzHJZg80mM+MT0+XZ4ZDDjPIyWywMy8cR8MxxkRdiDNJiRwRTwaC/M36v+gZqVsveaHIh17kjPPzX+5//9kmY/GEq220vt7tF8w71O20biT+TWW9g==; s=smtpoutjames; d=linagora.com; v=1; bh=fFpjrinCSEr9IVthaONoBchpXkfPaZOaDd5zn86KcSQ=; h=from : reply-to : subject : date : to : cc : resent-date : resent-from : resent-sender : resent-to : resent-cc : in-reply-to : references : list-id : list-help : list-unsubscribe : list-subscribe : list-post : list-owner : list-archive;
Date: Tue, 31 Jan 2023 07:45:06 +0000
Message-ID: <1354086525.65.1675151106357@212e230e4d2f>
MIME-Version: 1.0
X-LINAGORA-Copy-Delivery-Done: 1
From: rcordier@linagora.com
To: The IESG <iesg@ietf.org>, Paul Wouters via Datatracker <noreply@ietf.org>
Cc: draft-ietf-jmap-quotas@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, brong@fastmailteam.com
Reply-To: rcordier@linagora.com
User-Agent: Team-Mail/0.5.2 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36
Content-Type: multipart/alternative; boundary="-=Part.1f5.b7056ae0804c1fc6.18606c95ed3.55094a6a6e8ce626=-"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/5LBSFkoi6B4XEoszta2gQmfuffk>
Subject: Re: [Jmap] Paul Wouters' Discuss on draft-ietf-jmap-quotas-10: (with DISCUSS)
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 31 Jan 2023 07:45:13 -0000

Hello Paul,

Sorry for the late response and thank you for the review and feedback.

As this is a discuss, I will answer inline below.

If we still disagree please feel free to pursue the discussion.

Best regards,

Rene. 

On Dec 15, 2022 10:20 AM, from Paul Wouters Via Datatracker Paul Wouters has entered the following ballot position for
draft-ietf-jmap-quotas-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-jmap-quotas/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to Wes for his SECDIR review:
https://datatracker.ietf.org/doc/review-ietf-jmap-quotas-07-secdir-lc-hardaker-2022-11-17/
Some of his feedback seems to have already made it into the latest version of
the document.

I feel the types of quota limits has an interoperability issue ?

There are three limits: limit, warnLimit and softLimit. First, it would make
sense to rename the confusingly named "limit" to hardLimit.

If it makes it more clear I'm happy with it. I applied it in the latest version 11 of the draft.


I was puzzled about warnLimit not being the same as softLimit. What other
things does softLimit do than warn the user? Well, that is explained below this
and turns out to be "whatever the mailserver wants this to be". This is not
good for user expectations, unless they would get a detailed description along
with the warning what things will get blocked at the softLimit level, as there
is no longer a universal concept of what would happen at the softLimit level.
The examples in the document do not seem to use the description field for this
required user feedback. So when I get a warning from softLimit from Hotmail,
this could cause different limitations from when I get a warning from Gmail.
But as far as I can tell, the warning appears identical if the softLimit is
hit? Or did I miss where custom text can be given to the enduser for such
triggers?

I do get it can sound a bit confusing. You are right in a way it's not easing interoperability.

I tried to keep it relatively simple and flexible at the same time. Not everybody in the community seemed to want to use different levels of limits, but for some it seemed important (thus why it's optional). So not all servers might use it actually. And if they do, they might not want to block the same kind of things as well, as JMAP is quite generic for different data types, that have different usage (like you might not block the same kind of things depending if you are using your quota on mails or contacts for example) So I didn't want to complexify things. That's why I added in the optional description field that it can serve to explain what the limits, like the soft one, apply to. 

I did little changes though, let me know if it makes it a bit clearer for you or not: https://github.com/jmapio/jmap/pull/376/commits/275965bfc6838efca9140347b6b3d3659456ab1c

I do understand the concern with interoperability though. If you think we really need an extra optional field to add a description for the softLimit only for the end user then let me know and I would be happy to discuss a bit more with you.