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


   This specification defines sharing calendars between users on a
   CalDAV server.

Status of This Memo

   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

   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 Notice

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

Pot, et al.             Expires December 29, 2016               [Page 1]

Internet-Draft           CalDAV Calendar Sharing               June 2016

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   2
   3.  Calendar sharing  . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Per-instance calendar data  . . . . . . . . . . . . . . . . .   3
   5.  Scheduling  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     5.1.  The CALDAV:calendar-user-address-set WebDAV property  . .   4
     5.2.  Scheduling on read-only calendars . . . . . . . . . . . .   4
     5.3.  Example use-case: a secretary . . . . . . . . . . . . . .   4
     5.4.  Example use-case: a team calendar . . . . . . . . . . . .   5
     5.5.  Effects on schedule-default-calendar-url  . . . . . . . .   5
     5.6.  Effects on items delivered to the scheduling inbox  . . .   5
     5.7.  Calendar objects appearing more than once in a calendar-
           home  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.8.  Contribution towards free-busy  . . . . . . . . . . . . .   6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  Change History . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   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.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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.

Pot, et al.             Expires December 29, 2016               [Page 2]

Internet-Draft           CalDAV Calendar Sharing               June 2016

3.  Calendar sharing

   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.

4.  Per-instance calendar data

   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

   For calendaring object resources in shared calendar collections, the
   server MUST treat the following iCalendar data objects as per-

      TRANSP property

      VALARM component

5.  Scheduling

   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

   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.

Pot, et al.             Expires December 29, 2016               [Page 3]

Internet-Draft           CalDAV Calendar Sharing               June 2016

   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

5.1.  The CALDAV:calendar-user-address-set WebDAV property

   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.

5.2.  Scheduling on read-only calendars

   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.

5.3.  Example use-case: a secretary

   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.

Pot, et al.             Expires December 29, 2016               [Page 4]

Internet-Draft           CalDAV Calendar Sharing               June 2016

5.4.  Example use-case: a team calendar

   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.

5.5.  Effects on schedule-default-calendar-url

   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.

5.6.  Effects on items delivered to the scheduling inbox

   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.

Pot, et al.             Expires December 29, 2016               [Page 5]

Internet-Draft           CalDAV Calendar Sharing               June 2016

5.7.  Calendar objects appearing more than once in a calendar-home

   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.

5.8.  Contribution towards free-busy

   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

6.  Normative References

   [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,

Pot, et al.             Expires December 29, 2016               [Page 6]

Internet-Draft           CalDAV Calendar Sharing               June 2016

   [RFC4918]  Dusseault, L., Ed., "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,

Appendix A.  Change History

   Changes in -01:

   1.  Added support for CALDAV:calendar-user-address-set on calendars.

   2.  Add a large amount of detailed information about scheduling-
       related behavior.

Authors' Addresses

   Evert Pot
   fruux GmbH
   Koenigsstrasse 32
   Muenster, NRW  48143


   Cyrus Daboo
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014


Pot, et al.             Expires December 29, 2016               [Page 7]

Internet-Draft           CalDAV Calendar Sharing               June 2016

   Eric York
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014


Pot, et al.             Expires December 29, 2016               [Page 8]