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

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 15 Dec 2020 17:01:13 +1100

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.

---

From: Joris Baum <[email-masked]>
Date: Tue, 15 Dec 2020 09:21:37 +0100

Hi Neil,

sounds like a good idea. From what I can see one would currently need to 
reuse the CalendarPrincipal and CalendarShareNotification for specs that 
are somehow similar to JMAP for Calendars. I would have done it like 
that in JMAP for Tasks (and probably also Notes). Since CalDAV also 
defines tasks and notes and the JMAP spec relates to CalDAV, reusing 
sharing primitives prefixed by "Calendar" would probably only be 
semi-weird :P. I like dropping the "Calendar" prefix, because it would 
make it clearer that they are generic sharing primitives and not 
specific to calendars.

There may be similar issues with other primitives or methods that are 
defined in JMAP for Calendars. I am currently planning on keeping JMAP 
for Tasks as close as possible to JMAP for Calendars (similar to how 
CalDAV does it). The simplest way that I can see, would be to redefine a 
nearly identical primitive like CalendarEventNotification called 
TaskNotification. I also do not expect most of the method calls to 
deviate all too much from what is defined in JMAP for Calendars. This is 
why I am planning on simply referencing the methods from JMAP for 
Calendars instead of copy+pasting the definition into JMAP for Tasks 
(and probably Notes as well). Maybe there is a better way that I am 
currently not seeing, or we could move even more into a "generic" 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: "Jim Fenton" <[email-masked]>
Date: Tue, 15 Dec 2020 09:28:04 -0800

On 14 Dec 2020, at 22:01, Neil Jenkins wrote:

> calendars, tasks, mail sharing — to define how you share data of 
> types between entities within a system in a consistent way.
>

I definitely think that would be useful. For example, my wife and I 
would like to have a shared contact list.

-Jim

---

From: Ken Murchison <[email-masked]>
Date: Tue, 15 Dec 2020 12:29:34 -0500

> types to propose for acceptance.

+1 to splitting

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 16 Dec 2020 15:15:36 +1100

My public +1 as well :)  (Neil and I already discussed this on a call)

Bron.

On Wed, Dec 16, 2020, at 04:29, Ken Murchison wrote:

Kenneth Murchison

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 16 Dec 2020 16:05:04 +1100

OK, I've published an initial draft <https://datatracker.ietf.org/doc/draft-jenkins-jmap-sharing/> that splits off the principals/share notifications; I presume the next step is a call for adoption? I can then publish an update to the calendar spec that references this,

On Tue, 15 Dec 2020, at 19:21, Joris Baum wrote:
> I also do not expect most of the method calls to deviate all too much from what is defined in JMAP for Calendars. This is why I am planning on simply referencing the methods from JMAP for Calendars instead of copy+pasting the definition into JMAP for Tasks (and probably Notes as well). Maybe there is a better way that I am currently not seeing, or we could move even more into a "generic" spec?

I think it will be cleaner if JMAP Tasks is a sibling rather than dependent spec to JMAP Calendars, but it will be easier to discuss once we have a concrete initial draft.

Cheers,
Neil.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Dec 2020 10:42:11 +0000

Hi Neil,

> between entities within a system in a consistent way.

CalendarShareNotification is referencing CalendarRights. The latter 
looks rather calendar specific.

If you can generalize CalendarRights, what you suggest above looks like 
a good direction.

> types to propose for acceptance.

Best Regards,

Alexey