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

From: Joris Baum <[email-masked]>
Date: Mon, 1 Feb 2021 10:24:18 +0100

Hi Neil,

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? Some clients/servers might not want to implement one of these 
features. Also, splitting it will make the calendar spec more 
lightweight. On the downside, we might end up with a more fragmented spec.

Regards,

Joris

On 15.12.20 07:01, Neil Jenkins wrote:
> Hi all,
>
> The JMAP Calendars draft-in-progress currently defines the 
> CalendarPrincipal and CalendarShareNotification data types under a 
> separate capability. Looking at it, I have come to the conclusion that 
> we should go a step further: drop "Calendar" from the names and split 
> them out into their own spec. These are really generic sharing 
> primitives that could then be referenced by the other specs — e.g. 
> calendars, tasks, mail sharing — to define how you share data of types 
> between entities within a system in a consistent way.
>
> Please reply with any comments, questions, objections, or agreement 
> with the proposal and I will write up a draft splitting out these data 
> types to propose for acceptance.
>
> Cheers,
> Neil.
>
> _______________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap

-- 
Joris Baum
Tel: +49 721 170293 16
Fax: +49 721 170293 179

http://www.audriga.com | http://www.twitter.com/audriga

--------------------------------------------------------------------------
audriga GmbH | Durlacher Allee 47 | 76131 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
--------------------------------------------------------------------------

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 02 Feb 2021 13:49:22 +1100

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.

---

From: Hans-Joerg Happel <[email-masked]>
Date: Tue, 2 Feb 2021 14:34:32 +0100

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:
>> 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.
>

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

[email-masked]
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

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 03 Feb 2021 12:08:53 +1100

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.