Re: [Jmap] Roman Danyliw's No Objection on draft-ietf-jmap-quotas-10: (with COMMENT)
rcordier@linagora.com Thu, 02 February 2023 09:09 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 D76FAC14CE5D; Thu, 2 Feb 2023 01:09:17 -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 33pypsBF6v2y; Thu, 2 Feb 2023 01:09:13 -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 C6112C14CE53; Thu, 2 Feb 2023 01:09:10 -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 5AC603EE62; Thu, 2 Feb 2023 10:09:07 +0100 (CET)
DKIM-Signature: a=rsa-sha256; b=GfzQZI8J/xTHpcKVvDm8t2Wqh47WNi8Wy4XbDsyo3dhT5nCZCy95zUzbhNU+OELXX7z75Zv6W3MwiOrVjLcaNGN5NUWz0LhFK5tv0J7i9hkGbOZcoJg039WiRbGuUIuTWxfzGFEfp5TMI5pItNpMN1FlSnKz6H7BJGSzkSeDeMlP0LYE9vRGoyhzBRRP266ju/sa7lBgoH/rmIprd1DH06kFD0f88B7YPXm9EyYtEa/QKK4wyGhYNdr8AYe/GL/NaTsbJ731AuNxVk3k3J0kYGr3ofpnjJvT4Ze1HN0XMOvVNY//zLB0ea3ZGngQroyjlJMwYXSJHylCS/CZJfFdKQ==; s=smtpoutjames; d=linagora.com; v=1; bh=yrttKacORLNmJRIgiPzxRFLh+/TE4kzJcwX/HTKdKoE=; 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: Thu, 02 Feb 2023 09:09:07 +0000
Message-ID: <1545789496.92.1675328947884@212e230e4d2f>
MIME-Version: 1.0
X-LINAGORA-Copy-Delivery-Done: 1
From: rcordier@linagora.com
To: The IESG <iesg@ietf.org>, Bron Gondwana via Datatracker <noreply@ietf.org>, Bron Gondwana <brong@fastmailteam.com>
Cc: draft-ietf-jmap-quotas@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org
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.317.903e5a876fdafb44.1861163016d.a90bf369ee1ffc36=-"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/uL4rmv3C0npMbwg_rws1-lbfMfU>
Subject: Re: [Jmap] Roman Danyliw's No Objection on draft-ietf-jmap-quotas-10: (with COMMENT)
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: Thu, 02 Feb 2023 09:09:17 -0000
Hi Bron, I get your point, I saw the changes in the github and I'm totally ok with that. I just commented on a little typo but it's very appreciated :) Regards, Rene. On Feb 2, 2023 11:47 AM, from Bron Gondwana On Tue, Jan 31, 2023, at 19:18, rcordier@linagora.com wrote: ** Section 4. dataTypes. Where do the permitted values for dataTypes come from? Are these values standardized? It depends of what JMAP specifications the server implements, so it could vary. Each JMAP object has a data type of the same name. It could represent Email, Mailbox, Contact, Calendar, Event, ... depending if the server implements the related specs or not. That's why the clients are being asked to ignore any data type that are unknown to them. I want to extend this discussion a little because dataTypes are more explicitly spelled out now in the Blob spec: https://datatracker.ietf.org/doc/draft-ietf-jmap-blob/ And indeed, IANA have already taken action and created a registry for them: https://www.iana.org/assignments/jmap/jmap.xhtml#jmap-data-types Having said that - Rene, we may want rename this 'types' to match RFC8620's push object. I already renamed it in Blob because of that. Regarding ignoring types - given that this quota response is always in response to a request which includes a "using" list of URNs, we could require the server to filter any quotas and resource types that the client doesn't understand! I might actually just write a pull request against the spec with some suggestions to align with Blob and the data-types registry. I have merged your PR against jmapio/jmap and then issued my own PR with my suggestions: https://github.com/jmapio/jmap/pull/378 Hopefully you find that more useful than me describing the suggestions with words! Regards, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com
- [Jmap] Roman Danyliw's No Objection on draft-ietf… Roman Danyliw via Datatracker
- Re: [Jmap] Roman Danyliw's No Objection on draft-… rcordier
- Re: [Jmap] Roman Danyliw's No Objection on draft-… Bron Gondwana
- Re: [Jmap] Roman Danyliw's No Objection on draft-… rcordier
- Re: [Jmap] Roman Danyliw's No Objection on draft-… Bron Gondwana
- Re: [Jmap] Roman Danyliw's No Objection on draft-… rcordier