| Network Working Group | E. Pot |
| Internet-Draft | fruux GmbH |
| Expires: December 29, 2016 | C. Daboo |
| E. York | |
| Apple Inc. | |
| June 27, 2016 |
CalDAV Calendar Sharing
draft-pot-caldav-sharing-01
This specification defines sharing calendars between users on a CalDAV server.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 29, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Users of CalDAV [RFC4791] often require a mechanism to share a calendar with other users.
In the past this use-case has been fulfilled by non-standard means. This specification aims to describe a standard way for clients and servers to share calendars.
Sharing calendars is for the most part completely implemented using draft-pot-webdav-resource-sharing, but there are a few considerations specific to CalDAV to ensure that mechanisms such as scheduling still behaves as expected.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
When XML element types in the namespaces "DAV:" and "urn:ietf:params:xml:ns:caldav" are referenced in this document outside of the context of an XML fragment, the string "DAV:" and "CALDAV:" will be prefixed to the element type names respectively.
While the draft-pot-webdav-resource-sharing specification allows sharing of potentially any resource on a server, this specification only concerns itself with sharing calendar collections, as defined in CalDAV [RFC4791].
Sharing of resources other than calendar collections is not addressed in this specification.
Servers that support calendar sharing MUST support "per-instance" calendar data in calendar object resources stored in shared calendars. This allows each sharee and the sharer to store their own alarms and free busy transparency status without "interfering" with other users who also have access to the same calendar object resources.
For calendaring object resources in shared calendar collections, the server MUST treat the following iCalendar data objects as per-instance:
CalDAV Scheduling [RFC6638] 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 [RFC6638] 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 [RFC6638] 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".
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4791] | Daboo, C., Desruisseaux, B. and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, DOI 10.17487/RFC4791, March 2007. |
| [RFC4918] | Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, June 2007. |
| [RFC6352] | Daboo, C., "CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)", RFC 6352, DOI 10.17487/RFC6352, August 2011. |
| [RFC6638] | Daboo, C. and B. Desruisseaux, "Scheduling Extensions to CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012. |
| [RFC7303] | Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014. |
Changes in -01: