CalDAV Calendar Sharing
draft-pot-caldav-sharing-00

Abstract

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 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 July 14, 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 (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.

Table of Contents

• 1. Introduction
• 2. Open Issues
• 3. Conventions Used in This Document
• 4. Calendar sharing
• 5. Per-instance calendar data
• 6. Scheduling
• 7. Normative References
• Appendix A. Change History
• Authors' Addresses

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. Open Issues

1. DAV:owner requirement for scheduling. I think this is problematic...
2. I don't think we should allow sharees that have access to an invite for which they are the attendee for, via the organizers shared calendar, to allow them to make attendee-related changes. The entire collection should operate as if the operation is on behalf of the organizer.

3. Conventions Used in This Document

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.

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

5. 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 resources.

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

• TRANSP property
• VALARM component

6. 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 properties.

When a user interacts with a shared instance of a calendar, the agent and server must operate as if the operation is done on behalf of the sharee.

That means that if a new scheduling resource is created, the server MUST operate as if the calendar is a normal non-shared calendar owned by the sharee. This means that when doing scheduling operations on a shared calendar, the agents don't act on behalf of the original instance.

If a user is creating a new scheduling resource on a shared calendar, and an ATTENDEE listed on the scheduling resource also owns an instance of the shared calendar, the server MAY not create a new resource for the ATTENDEE. This is to avoid events appearing multiple times in a user's calendars.

A shared calendar MAY be specified in a user's CALDAV:schedule-default-calendar-url.

A user that appears as an ATTENDEE in a calendar object resource in a shared calendar, and DAV:read-write access is granted, the sharee is allowed to change not only iCalendar data related to the Organizer, but also data related to the Attendee. i.e., a sharee can change their own participation status on the "ATTENDEE" iCalendar property referring to them. Additionally, if the sharee is not listed as an Attendee, and write access is granted, the sharee can add themselves as an Attendee.

Following are additional considerations for scheduling with shared calendars:

1. A scheduled iCalendar component could appear in more than one calendar collection within a sharee's calendar home if the sharee is an Attendee and the Organizer or other Attendees have shared a calendar with the sharee that includes their copies of the iCalendar component. It is important to note that the scheduled component in the shared calendar could have different access rights than the one in the sharee's owned calendar.
2. A scheduled iCalendar component appearing in a sharee's shared calendar could include the sharee as an Attendee. For recurring events, it is possible for the sharee to only be listed as an Attendee in some instances, as opposed to all. Clients will need to be aware of this when allowing sharee's to set their own participation status.
3. In addition, when a shared calendar is first accepted by a sharee, the server SHOULD set the CALDAV:schedule-calendar-transp property to the value CALDAV:transparent to ensure newly accepted shared calendars do not contribute to the sharee's freebusy time until the sharee explicitly requests it.

7. Normative References

Appendix A. Change History

Authors' Addresses