Re: [Jmap] Proposal: split sharing mechanism from JMAP Calendars spec

Neil Jenkins <neilj@fastmailteam.com> Wed, 03 February 2021 01:09 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 C2D113A1154 for <jmap@ietfa.amsl.com>; Tue, 2 Feb 2021 17:09:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=N5e9/40F; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Igkf/0Dk
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 4B4cpdnEIbk3 for <jmap@ietfa.amsl.com>; Tue, 2 Feb 2021 17:09:03 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FCB3A115C for <jmap@ietf.org>; Tue, 2 Feb 2021 17:09:02 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 901855C031B for <jmap@ietf.org>; Tue, 2 Feb 2021 20:09:01 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Tue, 02 Feb 2021 20:09:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=TKpcLNX BMi58cACbsq4Hn7h3Skl/puSgoI1deYlQx3w=; b=N5e9/40FWzWT3f0ba57GBHt bVJJzGY0sgNkN8IA0Yx8owWCzuUz5DhF2sSUrnOSe3Ytsi7wlCG7mypujSYX/0QI n6JlssIYwkibFar7eJiwygyGqWBsbrF3I7g+puzYTY6ajOBqUuE6z1I45UWgPe7M 5WhVRi+UqpuD1/taCvhQNNqdPL6v48m2cUhdqWUjFkZdoUrINZTlqgHkSDKUXo6i 2Mki2+Us2D/IrTj5XX7dHrhoV++qziPj3BzBrkx1IJiT/APDgteNLUyzWsuHYzAr 3HmBqmbr1795mH8z1lYFkSTTfOOBGwbVgUQO6N1wAVdFTtcJ/egp/JoUxf4L2lA= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=TKpcLN XBMi58cACbsq4Hn7h3Skl/puSgoI1deYlQx3w=; b=Igkf/0DkVkin3RyemmZdRy UecwT2TFqduSFcH7ZoKkupSXXRsE8apQmIwScf7+fTwuxp3tMc4q8Yzc6YCfj5kZ XgvKu9IstX4sDDttxuXotuxv830YogQfAapOZzF5GvY8hEPPrWtK/C8QzCaNaHGl W0rewAbCLmiarBBDtxEpXJXpTTc7VTrDSWLUpQIlaKDrznfbqazU5xxMZbEWvTrl LuMOfeTXk/r1f/bQeavbEgknHHB2g5Cwm8/VO/iVZKwDEwBspYUDM3nrfwuRWIaQ KB5UhWi9YUIKzK1A7LD3GStQu8itPGKY/dIyq2/bgjl0vm2rw2tSckYRW2n97f0A ==
X-ME-Sender: <xms:rPcZYDjK2USTjgjW_RMWDxpmgYv2NaXlLIVY8zurLIi4H-QMzbDbGw> <xme:rPcZYACG_z-5Iy8wn4dTT9XQuvADqPZgCMCqDjDXSYWBh0lzi65L0N7h8VvffLrgu ZKrD5x0oQUD5Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrgedugdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepvedvtedvudelkefhgefhteeftedtlefhheefveffveelkedu tdduffeiveejvefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy: <xmx:rPcZYDFmkFF_zeSSxp2aAHR8oTWp7nJtJ2GFmt6f359tnsYF1W5WuQ> <xmx:rPcZYAT1Wm5cViQpartWnAlMnnFCQmvhqQp1_TMTKztOz6VUQuw-Vg> <xmx:rPcZYAyvz0hv1bZkM7csK1bKqAj8s6gzaFBJDYRi7612dmkiq25MrQ> <xmx:rfcZYP9DFLOlB7K_zvOJTPvLP81_IbfB-Ih3BbSEhDwpkPN9c7Nwcg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id AE63236005C; Tue, 2 Feb 2021 20:09:00 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-93-gef6c4048e6-fm-20210128.002-gef6c4048
Mime-Version: 1.0
Message-Id: <95c347f5-40c8-4642-a289-87104e1c01a5@dogfood.fastmail.com>
In-Reply-To: <c867eeb5-cd87-f73f-a24f-645ce9b4b874@audriga.com>
References: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> <3101d01e-a9b3-c5c6-fc2c-f57dcd0df533@audriga.com> <578c0b6d-4d6c-4470-9744-c6345d0fe029@dogfood.fastmail.com> <c867eeb5-cd87-f73f-a24f-645ce9b4b874@audriga.com>
Date: Wed, 03 Feb 2021 12:08:53 +1100
From: "Neil Jenkins" <neilj@fastmailteam.com>
To: "IETF JMAP Mailing List" <jmap@ietf.org>
Content-Type: multipart/alternative; boundary=2f1b19aec9ed4efdbd1f04eb7169f473
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/u5TFJn_VnaFpLIxa5ouCuFT0ZaM>
Subject: Re: [Jmap] Proposal: split sharing mechanism from JMAP Calendars spec
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: Wed, 03 Feb 2021 01:09:05 -0000

On Wed, 3 Feb 2021, at 00:34, Hans-Joerg Happel wrote:
> I would limit such capabilities to a handful of feature differences seen in existing task system. I do not see too much interrelation between those features.

> For fostering an open ecosystem, it would be great if man task systems and task apps could adopt JMAP for Tasks. Without a "capabilities" mechanism however, this would certainly be inhibited.


Right, so you're thinking of tasks rather than calendars. So we can look at making some things optional in JMAP tasks: I agree that the ability to assign participants may be reasonable to make optional there. But it's important to keep the options as few as possible, as otherwise the implementations become so different that it becomes very hard to build a good client that can handle all of them, so you miss out on the whole point of an open standard: interoperability.

Neil.