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

Hans-Joerg Happel <happel@audriga.com> Tue, 02 February 2021 13:34 UTC

Return-Path: <happel@audriga.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 9E6143A1ABF for <jmap@ietfa.amsl.com>; Tue, 2 Feb 2021 05:34:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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 FW2qT15_1hUT for <jmap@ietfa.amsl.com>; Tue, 2 Feb 2021 05:34:37 -0800 (PST)
Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96FE3A1ABD for <jmap@ietf.org>; Tue, 2 Feb 2021 05:34:37 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 692CCA1C8 for <jmap@ietf.org>; Tue, 2 Feb 2021 14:34:35 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mail.audriga.com
Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-MJcRhvnh5Q for <jmap@ietf.org>; Tue, 2 Feb 2021 14:34:32 +0100 (CET)
Received: from [192.168.10.154] (unknown [109.90.161.242]) (Authenticated sender: happel@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id B4202A1A2 for <jmap@ietf.org>; Tue, 2 Feb 2021 14:34:32 +0100 (CET)
To: jmap@ietf.org
References: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> <3101d01e-a9b3-c5c6-fc2c-f57dcd0df533@audriga.com> <578c0b6d-4d6c-4470-9744-c6345d0fe029@dogfood.fastmail.com>
From: Hans-Joerg Happel <happel@audriga.com>
Message-ID: <c867eeb5-cd87-f73f-a24f-645ce9b4b874@audriga.com>
Date: Tue, 2 Feb 2021 14:34:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <578c0b6d-4d6c-4470-9744-c6345d0fe029@dogfood.fastmail.com>
Content-Type: multipart/alternative; boundary="------------65D8231EA58BC10E85386DD4"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/b6rCC7EHx9RS_srsJbA6-CXEFiA>
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: Tue, 02 Feb 2021 13:34:40 -0000

Hi Neil,

the idea regarding more fine grained "capabilities" for the task feature 
stems from the purpose of using JMAP as an approach for data portability 
and/or also "modernizing" legacy groupware/task systems API's.

While, e.g., attendees/assignees or recurrences are a standard feature 
for calendars, in our observation the situation is quite different with 
task management. As one extreme, Google Tasks just supports a handful of 
task properties.

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.

Best,
Hans-Joerg

On 02.02.21 03:49, Neil Jenkins wrote:
> On Mon, 1 Feb 2021, at 20:24, Joris Baum wrote:
>>
>> another, related question would be if it would make sense for you to 
>> split the calendars capability even further to allow signalling that 
>> servers support features like recurrence, participants, relations or 
>> alerts?
>>
>
> No, I wouldn't split the spec on these. If there's something more 
> specific you have in mind (i.e. an existing server that has 
> particularly limited support) then we can look at making that optional 
> with a capability property to indicate server support, but each 
> additional one makes clients harder to write as you have to support 
> different levels (and combinations!) of capability.
>
> Neil.
>
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap


-- 
audriga GmbH
Durlacher Allee 47
76131 Karlsruhe, Germany
Tel: +49 (0) 721 17029 316
Fax: +49 (0) 721 17029 3179

support@audriga.com
https://www.audriga.com

Handelsregister: Amtsgericht Mannheim - HRB 713034
Sitz der Gesellschaft: Karlsruhe
Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel
USt-ID: DE 279724142