CalDAV Calendar Sharing

CalDAV Scheduling defines how a CalDAV server carries out scheduling operations when calendar object resources are created, modified or deleted and include "ORGANIZER" and "ATTENDEE" iCalendar properties. Normally when a server schedules events, the server will determine the intent of the user and the action to take by inspecting the "ATTENDEE" and "ORGANIZER" properties, and comparing this to the values of the CALDAV:calendar-user-address-set property defined on the principal resource of the user who owns the calendar-home in which the relevant calendar is contained. However, this can be problematic when a calendar is shared, and appears in multiple calendar collections. For example, if both sharer and sharee appear as an ORGANIZER of an event, a HTTP DELETE might either cause an event to be cancelled for everyone, or just DECLINED by an attendee depending on who is considered to be the relevant principal performing the action. This issue can be described more precisely as follows: if a user performs a scheduling operation on a scheduled calendar object, does the user act on behalf of theirselves, or on behalf of the sharer of the calendar? We've identified that there's some use-cases where you'd want the user to act on behalf of theirselves, and some where the action should be on behalf of the owner. This specification supports both use-cases.

Section 2.4.1 of describes a CALDAV:calendar-user-address-set WebDAV property defined on WebDAV principals. This specification extends its usage and allows it to also be defined on individual calendars. Clients conforming to this specification should inspect every calendar for the existance of this property before doing scheduling operations, whether the calendar is shared or not. Only if the property is not defined on a calendar, it should fall back to the "CALDAV:calendar-user-address-set" property defined on the principal which owns the calendar-home in which the calendar is contained in. This allows a CalDAV server to indicate to clients on behalf of whom the user-agent should perform scheduling operations.

Clients and Servers should NOT allow a user to perform scheduling operations on calendar objects appearing in calendars for which they were not granted read-write access.

A user might need a different user on a calendaring system to manage his or her calendars. This person might be a secretary acting on behalf of a busy individual. In this particular use-case, when the secretary creates an event, or accepts an invitation, the action must be taken on behalf of the owner of the calendar. Therefore, the CalDAV server should provide a CALDAV:calendar-user-address-set property on the sharee's instance of the calendar. This property should contain the same value as the CALDAV:calendar-user-address-set property set on the sharer's principal resource.

On a calendaring server, there might be a calendar containing events which is shared to an team of several people. This calendar might contain regular meetings for various members in the team. The team calendar is shared to everyone to keep people in the loop with who is meeting who. When a new scheduling object is created by a user, and this user invites several attendees who are also members of the team, these members need to be able to update their attendence status. In this scenario, every sharee acts on behalf of theirselves in the context of the team calendar. Therefore, the CALDAV:calendar-user-address-set property should for every instance of the shared calendar either be omitted, or match the sharee principal's value for CALDAV:calendar-user-address-set.

The schedule-default-calendar-url WebDAV property, which is defined in Section 9.2 of defines in which CalDAV calendar new invitations should be delivered. This specification restricts this property further. The value of schedule-default-calendar-url MUST NOT point to a calendar for which the CALDAV:calendar-user-address-set property is defined and does not match the value of the principal schedule-default-calendar-url is pointing to.

RFC6638 defines a "Scheduling Inbox Collection". This collection contains notifications of scheduling messages. If a user is performing scheduling operations on behalf of another user, a CalDAV server MAY also choose to deliver scheduling notifications to sharees for calendars owned by a different user. If a CalDAV server implements this, the CalDAV server MUST only deliver scheduling messages that relate to scheduling objects that appear on shared calendars.

Implementors of this specification should be aware a calendar object with a particular UID might appear more than once in a single users' calendar home. An example of this is a situation where a user invites a user to an event, and then also invites the same user to share the calendar where the invitiation was created. The event might also contain vastly different information. The user might for example only have been invited to a single instance of a recurring event. Calendaring user agents MAY coelesce events that appear on multiple calendars via their user interface. A server MUST NOT de-duplicate events.

When calculating free-busy information, the CALDAV:calendar-user-address-set property must be considered. The implication is that if the CALDAV:calendar-user-address-set is set on a calendar, and it doesn't match the CALDAV:calendar-user-address-set for whom the freebusy report is requested, then the CALDAV:calendar-user-address-set set on the calendar MUST be used to calculate the report. However, generally shared calendars in which you schedule on behalf of a different user should not be considered, because they SHOULD have a "CALDAV:schedule-calendar-transp" property set with a value of "CALDAV:transparent".