idnits 2.17.1 draft-pot-caldav-sharing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 11, 2016) is 3027 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4918' is defined on line 195, but no explicit reference was found in the text == Unused Reference: 'RFC6352' is defined on line 200, but no explicit reference was found in the text == Unused Reference: 'RFC7303' is defined on line 209, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Pot 3 Internet-Draft fruux GmbH 4 Expires: July 14, 2016 C. Daboo 5 E. York 6 Apple Inc. 7 January 11, 2016 9 CalDAV Calendar Sharing 10 draft-pot-caldav-sharing-00 12 Abstract 14 This specification defines sharing calendars between users on a 15 CalDAV server. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 14, 2016. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Conventions Used in This Document . . . . . . . . . . . . . . 2 54 4. Calendar sharing . . . . . . . . . . . . . . . . . . . . . . 3 55 5. Per-instance calendar data . . . . . . . . . . . . . . . . . 3 56 6. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 58 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 5 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 61 1. Introduction 63 Users of CalDAV [RFC4791] often require a mechanism to share a 64 calendar with other users. 66 In the past this use-case has been fulfilled by non-standard means. 67 This specification aims to describe a standard way for clients and 68 servers to share calendars. 70 Sharing calendars is for the most part completely implemented using 71 draft-pot-webdav-resource-sharing, but there are a few considerations 72 specific to CalDAV to ensure that mechanisms such as scheduling still 73 behaves as expected. 75 2. Open Issues 77 1. DAV:owner requirement for scheduling. I think this is 78 problematic... 80 2. I don't think we should allow sharees that have access to an 81 invite for which they are the attendee for, via the organizers 82 shared calendar, to allow them to make attendee-related changes. 83 The entire collection should operate as if the operation is on 84 behalf of the organizer. 86 3. Conventions Used in This Document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 When XML element types in the namespaces "DAV:" and 93 "urn:ietf:params:xml:ns:caldav" are referenced in this document 94 outside of the context of an XML fragment, the string "DAV:" and 95 "CALDAV:" will be prefixed to the element type names respectively. 97 4. Calendar sharing 99 While the draft-pot-webdav-resource-sharing specification allows 100 sharing of potentially any resource on a server, this specification 101 only concerns itself with sharing calendar collections, as defined in 102 CalDAV [RFC4791]. 104 Sharing of resources other than calendar collections is not addressed 105 in this specification. 107 5. Per-instance calendar data 109 Servers that support calendar sharing MUST support "per-instance" 110 calendar data in calendar object resources stored in shared 111 calendars. This allows each sharee and the sharer to store their own 112 alarms and free busy transparency status without "interfering" with 113 other users who also have access to the same calendar object 114 resources. 116 For calendaring object resources in shared calendar collections, the 117 server MUST treat the following iCalendar data objects as per- 118 instance: 120 TRANSP property 122 VALARM component 124 6. Scheduling 126 CalDAV Scheduling [RFC6638] defines how a CalDAV server carries out 127 scheduling operations when calendar object resources are created, 128 modified or deleted and include "ORGANIZER" and "ATTENDEE" iCalendar 129 properties. 131 When a user interacts with a shared instance of a calendar, the agent 132 and server must operate as if the operation is done on behalf of the 133 sharee. 135 That means that if a new scheduling resource is created, the server 136 MUST operate as if the calendar is a normal non-shared calendar owned 137 by the sharee. This means that when doing scheduling operations on a 138 shared calendar, the agents don't act on behalf of the original 139 instance. 141 If a user is creating a new scheduling resource on a shared calendar, 142 and an ATTENDEE listed on the scheduling resource also owns an 143 instance of the shared calendar, the server MAY not create a new 144 resource for the ATTENDEE. This is to avoid events appearing 145 multiple times in a user's calendars. 147 A shared calendar MAY be specified in a user's CALDAV:schedule- 148 default-calendar-url. 150 A user that appears as an ATTENDEE in a calendar object resource in a 151 shared calendar, and DAV:read-write access is granted, the sharee is 152 allowed to change not only iCalendar data related to the Organizer, 153 but also data related to the Attendee. i.e., a sharee can change 154 their own participation status on the "ATTENDEE" iCalendar property 155 referring to them. Additionally, if the sharee is not listed as an 156 Attendee, and write access is granted, the sharee can add themselves 157 as an Attendee. 159 Following are additional considerations for scheduling with shared 160 calendars: 162 1. A scheduled iCalendar component could appear in more than one 163 calendar collection within a sharee's calendar home if the sharee 164 is an Attendee and the Organizer or other Attendees have shared a 165 calendar with the sharee that includes their copies of the 166 iCalendar component. It is important to note that the scheduled 167 component in the shared calendar could have different access 168 rights than the one in the sharee's owned calendar. 170 2. A scheduled iCalendar component appearing in a sharee's shared 171 calendar could include the sharee as an Attendee. For recurring 172 events, it is possible for the sharee to only be listed as an 173 Attendee in some instances, as opposed to all. Clients will need 174 to be aware of this when allowing sharee's to set their own 175 participation status. 177 3. In addition, when a shared calendar is first accepted by a 178 sharee, the server SHOULD set the CALDAV:schedule-calendar-transp 179 property to the value CALDAV:transparent to ensure newly accepted 180 shared calendars do not contribute to the sharee's freebusy time 181 until the sharee explicitly requests it. 183 7. Normative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, 187 DOI 10.17487/RFC2119, March 1997, 188 . 190 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 191 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 192 DOI 10.17487/RFC4791, March 2007, 193 . 195 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 196 Authoring and Versioning (WebDAV)", RFC 4918, 197 DOI 10.17487/RFC4918, June 2007, 198 . 200 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed 201 Authoring and Versioning (WebDAV)", RFC 6352, 202 DOI 10.17487/RFC6352, August 2011, 203 . 205 [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to 206 CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012, 207 . 209 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 210 DOI 10.17487/RFC7303, July 2014, 211 . 213 Appendix A. Change History 215 Authors' Addresses 217 Evert Pot 218 fruux GmbH 219 Koenigsstrasse 32 220 Muenster, NRW 48143 221 Germany 223 Email: me@evertpot.com 224 URI: https://fruux.com/ 226 Cyrus Daboo 227 Apple Inc. 228 1 Infinite Loop 229 Cupertino, CA 95014 230 USA 232 Email: cyrus@daboo.name 233 URI: http://www.apple.com/ 234 Eric York 235 Apple Inc. 236 1 Infinite Loop 237 Cupertino, CA 95014 238 USA 240 URI: http://www.apple.com/