[Docs] [txt|pdf|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01
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
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 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
(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.
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",
"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.
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
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
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
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.
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
use-cases.
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
"CALDAV:transparent".
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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
DOI 10.17487/RFC4791, March 2007,
<http://www.rfc-editor.org/info/rfc4791>.
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,
<http://www.rfc-editor.org/info/rfc4918>.
[RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed
Authoring and Versioning (WebDAV)", RFC 6352,
DOI 10.17487/RFC6352, August 2011,
<http://www.rfc-editor.org/info/rfc6352>.
[RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012,
<http://www.rfc-editor.org/info/rfc6638>.
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
DOI 10.17487/RFC7303, July 2014,
<http://www.rfc-editor.org/info/rfc7303>.
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
Germany
Email: me@evertpot.com
URI: https://fruux.com/
Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
Email: cyrus@daboo.name
URI: http://www.apple.com/
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
USA
URI: http://www.apple.com/
Pot, et al. Expires December 29, 2016 [Page 8]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/