IETF Logo Mail Archive

Re: [Jmap] Question: Mandate core capability on each API call?

Benoît TELLIER <btellier@linagora.com> Tue, 01 December 2020 06:33 UTC

Return-Path: <btellier@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 C07D43A0B5A for <jmap@ietfa.amsl.com>; Mon, 30 Nov 2020 22:33:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.221
X-Spam-Level:
X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGPGz_phi_oA for <jmap@ietfa.amsl.com>; Mon, 30 Nov 2020 22:33:19 -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 011203A0B54 for <jmap@ietf.org>; Mon, 30 Nov 2020 22:33:18 -0800 (PST)
Received: from ?Open?PaaS?SMTP?server?for?Linagora? (incoming.linagora.com [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 8877D3F39E for <jmap@ietf.org>; Tue, 1 Dec 2020 07:33:15 +0100 (CET)
MIME-Version: 1.0
DKIM-Signature: a=rsa-sha256; b=qKNaPhobzXVen4Ha9XBjxPu3VziwrDlM7VoLfA73kVGnnUBW0Ljf0Uyr3p7yFcHvt9y1urtQyTt8czxz7fJI2/VVDOEpZAJwZwqrFPQF0kMZ1qvuVI9s8/RdaPys24T47runr9xqxfU+H9dP0Oa/z+BSbzM0glkr9RRhDjWNdff3ZEgOHrscnMPdEWA8e+mj4IBzKHHKo4Y6rdGJ1XChp7PXK+Zay6BbE7YnmyOTGJOasjC8zTzgexuswcecOcfOJm24kPzSB2K9q9K/hlpJmcWQKuzJHYnJRRVhGPwnl+psqQUHqqTSSFqSWpgwhtWuEchRkZIstYey3LMwpUWduQ==; s=smtpoutjames; d=linagora.com; v=1; bh=sMgT+C93uSv+wQVAiQ/zAx9OIDmEu6qIhMIklsBpISQ=; 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;
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-LINAGORA-Copy-Delivery-Done: 1
From: Benoît TELLIER <btellier@linagora.com>
Sender: Benoît TELLIER <btellier@linagora.com>
Reply-To: btellier@linagora.com
To: IETF JMAP Mailing List <jmap@ietf.org>
Message-ID: <Mime4j.674.8fd62851891e02d1.1761d01528b@linagora.com>
Date: Tue, 01 Dec 2020 06:33:14 +0000
References: <a769713e-62ef-0eef-b61d-7fa64a8371ce@linagora.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/tdru8X0DOfQN_vRZJM28V_TaHdQ>
Subject: Re: [Jmap] Question: Mandate core capability on each API call?
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: Tue, 01 Dec 2020 06:33:21 -0000

Hi Neil,

Thanks for the answer.

It is not explicitly asked in the RFC so there is no reasons for server implementations to enforce it then.

I will likely relax the James expectations regarding this.

The explanation behind it would be that the session provides you an API endpoint compatible with the core capability, thus the redundant capability can be ignored.

Maybe we should warn in the client guide that including the core capability is advised, while waiting for the erratum?

Cheers,

Benoit

On December 1, 2020 11:18 AM, from neilj@fastmailteam.com
Hi Benoit,

Good question! I thought we had specified this, but I can't see it in the final draft. I don't see any particular downside to making it optional, but perhaps someone else has an argument as to why it should be mandatory? Whatever we decide, it is probably worth an erratum for the benefit of future implementors.

Neil.

v2.23.0 | Report a Bug | By Email