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

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
> Jmap@ietf.org
> 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
--------------------------------------------------------------------------