idnits 2.17.1 draft-pot-caldav-sharing-01.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 (June 27, 2016) is 2859 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 282, but no explicit reference was found in the text == Unused Reference: 'RFC6352' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'RFC7303' is defined on line 296, 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: December 29, 2016 C. Daboo 5 E. York 6 Apple Inc. 7 June 27, 2016 9 CalDAV Calendar Sharing 10 draft-pot-caldav-sharing-01 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 December 29, 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. Conventions Used in This Document . . . . . . . . . . . . . . 2 53 3. Calendar sharing . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Per-instance calendar data . . . . . . . . . . . . . . . . . 3 55 5. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 5.1. The CALDAV:calendar-user-address-set WebDAV property . . 4 57 5.2. Scheduling on read-only calendars . . . . . . . . . . . . 4 58 5.3. Example use-case: a secretary . . . . . . . . . . . . . . 4 59 5.4. Example use-case: a team calendar . . . . . . . . . . . . 5 60 5.5. Effects on schedule-default-calendar-url . . . . . . . . 5 61 5.6. Effects on items delivered to the scheduling inbox . . . 5 62 5.7. Calendar objects appearing more than once in a calendar- 63 home . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.8. Contribution towards free-busy . . . . . . . . . . . . . 6 65 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 66 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 Users of CalDAV [RFC4791] often require a mechanism to share a 72 calendar with other users. 74 In the past this use-case has been fulfilled by non-standard means. 75 This specification aims to describe a standard way for clients and 76 servers to share calendars. 78 Sharing calendars is for the most part completely implemented using 79 draft-pot-webdav-resource-sharing, but there are a few considerations 80 specific to CalDAV to ensure that mechanisms such as scheduling still 81 behaves as expected. 83 2. Conventions Used in This Document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 When XML element types in the namespaces "DAV:" and 90 "urn:ietf:params:xml:ns:caldav" are referenced in this document 91 outside of the context of an XML fragment, the string "DAV:" and 92 "CALDAV:" will be prefixed to the element type names respectively. 94 3. Calendar sharing 96 While the draft-pot-webdav-resource-sharing specification allows 97 sharing of potentially any resource on a server, this specification 98 only concerns itself with sharing calendar collections, as defined in 99 CalDAV [RFC4791]. 101 Sharing of resources other than calendar collections is not addressed 102 in this specification. 104 4. Per-instance calendar data 106 Servers that support calendar sharing MUST support "per-instance" 107 calendar data in calendar object resources stored in shared 108 calendars. This allows each sharee and the sharer to store their own 109 alarms and free busy transparency status without "interfering" with 110 other users who also have access to the same calendar object 111 resources. 113 For calendaring object resources in shared calendar collections, the 114 server MUST treat the following iCalendar data objects as per- 115 instance: 117 TRANSP property 119 VALARM component 121 5. Scheduling 123 CalDAV Scheduling [RFC6638] defines how a CalDAV server carries out 124 scheduling operations when calendar object resources are created, 125 modified or deleted and include "ORGANIZER" and "ATTENDEE" iCalendar 126 properties. 128 Normally when a server schedules events, the server will determine 129 the intent of the user and the action to take by inspecting the 130 "ATTENDEE" and "ORGANIZER" properties, and comparing this to the 131 values of the CALDAV:calendar-user-address-set property defined on 132 the principal resource of the user who owns the calendar-home in 133 which the relevant calendar is contained. However, this can be 134 problematic when a calendar is shared, and appears in multiple 135 calendar collections. 137 For example, if both sharer and sharee appear as an ORGANIZER of an 138 event, a HTTP DELETE might either cause an event to be cancelled for 139 everyone, or just DECLINED by an attendee depending on who is 140 considered to be the relevant principal performing the action. 142 This issue can be described more precisely as follows: if a user 143 performs a scheduling operation on a scheduled calendar object, does 144 the user act on behalf of theirselves, or on behalf of the sharer of 145 the calendar? 147 We've identified that there's some use-cases where you'd want the 148 user to act on behalf of theirselves, and some where the action 149 should be on behalf of the owner. This specification supports both 150 use-cases. 152 5.1. The CALDAV:calendar-user-address-set WebDAV property 154 Section 2.4.1 of [RFC6638] describes a CALDAV:calendar-user-address- 155 set WebDAV property defined on WebDAV principals. 157 This specification extends its usage and allows it to also be defined 158 on individual calendars. 160 Clients conforming to this specification should inspect every 161 calendar for the existance of this property before doing scheduling 162 operations, whether the calendar is shared or not. Only if the 163 property is not defined on a calendar, it should fall back to the 164 "CALDAV:calendar-user-address-set" property defined on the principal 165 which owns the calendar-home in which the calendar is contained in. 167 This allows a CalDAV server to indicate to clients on behalf of whom 168 the user-agent should perform scheduling operations. 170 5.2. Scheduling on read-only calendars 172 Clients and Servers should NOT allow a user to perform scheduling 173 operations on calendar objects appearing in calendars for which they 174 were not granted read-write access. 176 5.3. Example use-case: a secretary 178 A user might need a different user on a calendaring system to manage 179 his or her calendars. This person might be a secretary acting on 180 behalf of a busy individual. 182 In this particular use-case, when the secretary creates an event, or 183 accepts an invitation, the action must be taken on behalf of the 184 owner of the calendar. 186 Therefore, the CalDAV server should provide a CALDAV:calendar-user- 187 address-set property on the sharee's instance of the calendar. This 188 property should contain the same value as the CALDAV:calendar-user- 189 address-set property set on the sharer's principal resource. 191 5.4. Example use-case: a team calendar 193 On a calendaring server, there might be a calendar containing events 194 which is shared to an team of several people. 196 This calendar might contain regular meetings for various members in 197 the team. The team calendar is shared to everyone to keep people in 198 the loop with who is meeting who. 200 When a new scheduling object is created by a user, and this user 201 invites several attendees who are also members of the team, these 202 members need to be able to update their attendence status. In this 203 scenario, every sharee acts on behalf of theirselves in the context 204 of the team calendar. 206 Therefore, the CALDAV:calendar-user-address-set property should for 207 every instance of the shared calendar either be omitted, or match the 208 sharee principal's value for CALDAV:calendar-user-address-set. 210 5.5. Effects on schedule-default-calendar-url 212 The schedule-default-calendar-url WebDAV property, which is defined 213 in Section 9.2 of [RFC6638] defines in which CalDAV calendar new 214 invitations should be delivered. 216 This specification restricts this property further. The value of 217 schedule-default-calendar-url MUST NOT point to a calendar for which 218 the CALDAV:calendar-user-address-set property is defined and does not 219 match the value of the principal schedule-default-calendar-url is 220 pointing to. 222 5.6. Effects on items delivered to the scheduling inbox 224 RFC6638 defines a "Scheduling Inbox Collection". This collection 225 contains notifications of scheduling messages. 227 If a user is performing scheduling operations on behalf of another 228 user, a CalDAV server MAY also choose to deliver scheduling 229 notifications to sharees for calendars owned by a different user. 231 If a CalDAV server implements this, the CalDAV server MUST only 232 deliver scheduling messages that relate to scheduling objects that 233 appear on shared calendars. 235 5.7. Calendar objects appearing more than once in a calendar-home 237 Implementors of this specification should be aware a calendar object 238 with a particular UID might appear more than once in a single users' 239 calendar home. 241 An example of this is a situation where a user invites a user to an 242 event, and then also invites the same user to share the calendar 243 where the invitiation was created. 245 The event might also contain vastly different information. The user 246 might for example only have been invited to a single instance of a 247 recurring event. 249 Calendaring user agents MAY coelesce events that appear on multiple 250 calendars via their user interface. 252 A server MUST NOT de-duplicate events. 254 5.8. Contribution towards free-busy 256 When calculating free-busy information, the CALDAV:calendar-user- 257 address-set property must be considered. 259 The implication is that if the CALDAV:calendar-user-address-set is 260 set on a calendar, and it doesn't match the CALDAV:calendar-user- 261 address-set for whom the freebusy report is requested, then the 262 CALDAV:calendar-user-address-set set on the calendar MUST be used to 263 calculate the report. 265 However, generally shared calendars in which you schedule on behalf 266 of a different user should not be considered, because they SHOULD 267 have a "CALDAV:schedule-calendar-transp" property set with a value of 268 "CALDAV:transparent". 270 6. Normative References 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, 274 DOI 10.17487/RFC2119, March 1997, 275 . 277 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 278 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 279 DOI 10.17487/RFC4791, March 2007, 280 . 282 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 283 Authoring and Versioning (WebDAV)", RFC 4918, 284 DOI 10.17487/RFC4918, June 2007, 285 . 287 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed 288 Authoring and Versioning (WebDAV)", RFC 6352, 289 DOI 10.17487/RFC6352, August 2011, 290 . 292 [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to 293 CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012, 294 . 296 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 297 DOI 10.17487/RFC7303, July 2014, 298 . 300 Appendix A. Change History 302 Changes in -01: 304 1. Added support for CALDAV:calendar-user-address-set on calendars. 306 2. Add a large amount of detailed information about scheduling- 307 related behavior. 309 Authors' Addresses 311 Evert Pot 312 fruux GmbH 313 Koenigsstrasse 32 314 Muenster, NRW 48143 315 Germany 317 Email: me@evertpot.com 318 URI: https://fruux.com/ 320 Cyrus Daboo 321 Apple Inc. 322 1 Infinite Loop 323 Cupertino, CA 95014 324 USA 326 Email: cyrus@daboo.name 327 URI: http://www.apple.com/ 328 Eric York 329 Apple Inc. 330 1 Infinite Loop 331 Cupertino, CA 95014 332 USA 334 URI: http://www.apple.com/