idnits 2.17.1 draft-pot-webdav-resource-sharing-04.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 12 characters in excess of 72. 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 2850 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 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 WebDAV Resource Sharing 10 draft-pot-webdav-resource-sharing-04 12 Abstract 14 This specification defines an extension to WebDAV that enables the 15 sharing of resources between users on a WebDAV 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 53 3. High-level overview . . . . . . . . . . . . . . . . . . . . . 4 54 4. Sharing a resource . . . . . . . . . . . . . . . . . . . . . 4 55 4.1. Advertising resource sharing support . . . . . . . . . . 5 56 4.2. Required privileges . . . . . . . . . . . . . . . . . . . 5 57 4.3. Sharing POST request . . . . . . . . . . . . . . . . . . 5 58 4.3.1. Example: Sharing a resource . . . . . . . . . . . . . 6 59 4.3.2. Example: Multiple sharee changes . . . . . . . . . . 7 60 4.4. New WebDAV properties on shared resources . . . . . . . . 8 61 4.4.1. DAV:share-access Property . . . . . . . . . . . . . . 8 62 4.4.2. DAV:invite Property . . . . . . . . . . . . . . . . . 9 63 4.4.3. DAV:share-resource-uri Property . . . . . . . . . . . 9 64 4.5. Handling the share process . . . . . . . . . . . . . . . 10 65 4.5.1. The invitation process . . . . . . . . . . . . . . . 10 66 4.5.2. Instant sharing . . . . . . . . . . . . . . . . . . . 11 67 4.6. Notification Definitions . . . . . . . . . . . . . . . . 11 68 4.6.1. Invite Notification . . . . . . . . . . . . . . . . . 11 69 4.6.1.1. Example: An invite notification . . . . . . . . . 11 70 4.6.2. Invite Reply . . . . . . . . . . . . . . . . . . . . 13 71 4.6.2.1. Example: An invite reply . . . . . . . . . . . . 13 72 4.7. Sharee Actions on Shared Resources . . . . . . . . . . . 14 73 4.7.1. Replying to a Sharing Invite . . . . . . . . . . . . 14 74 4.7.1.1. Example: Accepting an invite . . . . . . . . . . 15 75 4.7.2. Ignoring an invitation . . . . . . . . . . . . . . . 15 76 4.7.3. Making modifications to a shared resource . . . . . . 15 77 4.7.4. Removing a shared resource . . . . . . . . . . . . . 16 78 4.8. General Considerations . . . . . . . . . . . . . . . . . 16 79 4.8.1. Per-instance WebDAV Properties . . . . . . . . . . . 16 80 4.8.2. Sharees and instances . . . . . . . . . . . . . . . . 16 81 4.8.3. Relationship between sharing access levels and WebDAV 82 ACL . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 5. XML Element Definitions . . . . . . . . . . . . . . . . . . . 18 84 5.1. DAV:share-resource . . . . . . . . . . . . . . . . . . . 18 85 5.2. DAV:share . . . . . . . . . . . . . . . . . . . . . . . . 19 86 5.3. DAV:share-invite-notification . . . . . . . . . . . . . . 19 87 5.4. DAV:share-reply-notification . . . . . . . . . . . . . . 20 88 5.5. DAV:invite . . . . . . . . . . . . . . . . . . . . . . . 21 89 5.6. DAV:share-access . . . . . . . . . . . . . . . . . . . . 22 90 5.7. DAV:invite-reply . . . . . . . . . . . . . . . . . . . . 23 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 6.1. Forced shares . . . . . . . . . . . . . . . . . . . . . . 23 93 6.2. Notification spamming . . . . . . . . . . . . . . . . . . 24 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 95 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 96 9. Normative References . . . . . . . . . . . . . . . . . . . . 25 97 Appendix A. Backwards compatibility . . . . . . . . . . . . . . 26 98 Appendix B. Change History (to be removed prior to publication 99 as an RFC . . . . . . . . . . . . . . . . . . . . . 26 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 102 1. Introduction 104 Users of CalDAV [RFC4791] and CardDAV [RFC6352] often require a 105 mechanism to share a calendar or address book collection with other 106 users. 108 This specification introduces a mechanism that allows users of WebDAV 109 servers to invite another user to share a resource or WebDAV 110 collection. The invited user can either accept or reject the invite, 111 which is communicated back to the sharer. If the user chooses to 112 accept the invite, the shared resource will then appear in a location 113 on the server that's accessible by the invitee. 115 There are existing mechanism that address similar use-cases, such as 116 using WebDAV ACL [RFC3744] for fine-grained access control. 117 Experience has shown that client developers are averse to using it 118 due its complexity. Many implementations have chosen to only use 119 WebDAV ACL for communicating access control information to clients, 120 but not for modification. WebDAV ACL alone also does not provide the 121 means for a user to invite another user. 123 In this specification, HTTP POST operations are used to manage the 124 sharing invitations and replies, and WebDAV properties are used to 125 expose the state of shared resources. 127 This specification uses WebDAV notifications to communicate to users 128 there are outstanding invitations, or responses to invitations. 130 2. Conventions Used in This Document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 When XML element types in the namespace "DAV:" are referenced in this 137 document outside of the context of an XML fragment, the string "DAV:" 138 will be prefixed to the element type names. 140 Terms Used: 142 Sharer A user who is sharing a resource with other users. 144 Sharee A user to whom a resource has been shared. 146 Sharing Invite A message sent by a sharer to a sharee to notify a 147 sharee of an invitation or update. 149 Sharing Reply A message sent by a sharee to a sharer to indicate the 150 answer to an invite. 152 The DTD samples used in this document are for illustrative purposes 153 only. All XML documents in this document follow the conventions and 154 restrictions described in [RFC4918] section 17. 156 3. High-level overview 158 This section provides a basic overview of this protocol by way of a 159 simple use case of a sharer sharing a collection with a single 160 sharee. 162 To share a resource with another user, the sharer's client executes 163 an HTTP POST request against the resource that's to be shared. The 164 POST request body will contain details of the user to whom the 165 resource is to be shared as well as the access right to be granted to 166 them. If the request succeeds, a notification is sent to the sharee 167 with details of the resource being shared to them. 169 The sharee's client will show the notification to the sharee and 170 present them with the choice to accept or decline the invitation to 171 the shared collection. If the sharee chooses to decline, then 172 nothing changes for that sharee. If the sharee chooses to accept, 173 then a new resource is created at a location that's accessible to the 174 sharee. The server enforces the appropriate access privileges for 175 the sharee. 177 At any time, the sharer can inspect properties on the resource being 178 shared, and determine the accept/decline status of each sharee. 179 Additional sharees can be added and existing ones removed. The 180 access privileges for existing sharees can also be changed. 182 Once a sharee has access to the shared resource, they can remove it 183 and decline the sharing invite by simply having their client issue an 184 HTTP DELETE request on the shared collection. That does not delete 185 any data, but rather simply removes the "link" to the sharer's 186 resource and sets the sharee's invite status to declined. 188 4. Sharing a resource 189 4.1. Advertising resource sharing support 191 A server that supports the features described in this document MUST 192 include "resource-sharing" as a field in the DAV response header from 193 an OPTIONS request on any resource that supports these features. 195 A response to this OPTIONS request might look as follows: 197 HTTP/1.1 200 OK 199 Dav: 1,3,extended-mkcol,resource-sharing 200 Allow: GET,HEAD,POST,OPTIONS,PROPFIND,PROPPATCH 202 4.2. Required privileges 204 A server that supports sharing on a specific resource, MUST enforce 205 this using the "DAV:share" privilege. Privileges are defined in 206 [RFC3744]. 208 The privilege MAY be abstract and MAY be protected. This privilege 209 MUST appear in the DAV:supported-privilege-set property for resources 210 that may be shared. In addition, it MUST appear in the DAV:current- 211 user-privilege-set property, if the user is in fact allowed to share 212 the resource. This mechanism is also used by a client to discover 213 sharing capabilities on specific resources. 215 4.3. Sharing POST request 217 To share a resource or revoke access to a shared resource, the client 218 must issue a POST request to the resource that the user wants to 219 share. The POST request MUST contain an XML document as its body, 220 with the root element being DAV:share-resource (Section 5.1). 222 The POST request MUST contain a Content-Type HTTP header, which MUST 223 contain "application/davsharing+xml" as its value. Servers SHOULD 224 reject the request if this is not the case. 226 The DAV:share-resource element can contain one or more DAV:sharee 227 elements. Each DAV:sharee element MUST at least have a DAV:href 228 element containing a URI identifying the sharee. 230 The URI in DAV:href may be a principal-URL referring to a sharee 231 hosted on the same server, an email address or any other URI 232 identifying a user. In the case of the latter two, the sharee might 233 not be a user on the same server - though in that case how 234 invitations are sent or access is enabled is out of scope for this 235 specification. 237 The DAV:prop element is optional, and can be used to provide more 238 information about the sharee. The server MAY use this information 239 and later return it when information is requested about the list of 240 sharees. Any valid WebDAV property might be provided here, but it's 241 up to the discretion of the server what to support. A client SHOULD 242 provide at least a DAV:displayname property as a human- readable 243 string identifying the user. 245 The DAV:share-access element is required. It MUST contain one of the 246 following elements: 248 DAV:read When present this indicates that sharees can read 249 information from the resource, but cannot change it. This applies 250 to the resource, but if the shared resource is a collection, it 251 also applies to the collection's children. 253 DAV:read-write When present this indicates that sharees can read and 254 write information from the resource. 256 DAV:no-access When present this indicates that access to the 257 resource is revoked for the sharee. 259 Lastly, you may add the optional DAV:comment element. This element 260 may contain some information about the intent of the share, for the 261 sharee, this allows the sharee to send a short message. 263 4.3.1. Example: Sharing a resource 265 The following example grants read-write access to a resource 266 identified by "/calendars/users/cyrus/shared" to a sharee with email 267 address "mailto:eric@example.com". 269 POST /calendars/users/cyrus/shared/ HTTP/1.1 270 Host: calendar.example.com 271 Content-Type: application/davsharing+xml; charset="utf-8" 272 Content-Length: xxxx 274 275 276 277 mailto:eric@example.com 278 279 Eric York 280 281 Shared workspace 282 283 284 285 286 288 If the operation was successful, the server MUST respond with a 204 289 No Content HTTP status. 291 HTTP/1.1 200 OK 292 Cache-Control: no-cache 293 Date: Sat, 11 Nov 2006 09:32:12 GMT 295 4.3.2. Example: Multiple sharee changes 297 This example shows how multiple sharee's can be manipulated in a 298 single request. The sharee with email address 299 "mailto:eric@example.com" has their access downgraded to DAV:read, 300 whilst another sharee is removed from the access list entirely. 302 POST /calendars/users/cyrus/shared/ HTTP/1.1 303 Host: calendar.example.com 304 Content-Type: application/davsharing+xml; charset="utf-8" 305 Content-Length: xxxx 307 308 309 310 mailto:eric@example.com 311 312 313 314 315 316 mailto:wilfredo@example.com 317 318 319 320 321 323 4.4. New WebDAV properties on shared resources 325 The following new or modified WebDAV properties are defined for 326 resources and used to view or manipulate shared resources features. 328 4.4.1. DAV:share-access Property 330 Name: share-access 332 Namespace: DAV: 334 Purpose: Allows a client to see if a resource is a shared resource 335 and the access level. 337 Protected: This property MUST be protected. 339 PROPFIND behavior: This property SHOULD NOT be returned by a 340 PROPFIND allprop request (as defined in Section 14.2 of 341 [RFC4918]). 343 COPY/MOVE behavior: This property value MUST be preserved in MOVE 344 operations, but MUST NOT be preserved in COPY operations. 346 Description: Resources that are shared must have a DAV:share-access 347 property. It's value should be one of four elements: 349 * DAV:not-shared: Used to indicate that the resource is not 350 shared. This is the default, which means that if the 351 DAV:share-access is omitted, this value is implied. 353 * DAV:shared-owner: used to indicate that the resource is owned 354 by the current user and is being shared by them. 356 * DAV:read-write: used to indicate that the resource is shared, 357 and the current instance is the 'shared instance' which has 358 read-write access. 360 * DAV:read: used to indicate that the resource is shared, and the 361 current instance is the 'shared instance', and only read access 362 is provided. 364 4.4.2. DAV:invite Property 366 Name: invite 368 Namespace: DAV: 370 Purpose: Used to show to whom a resource has been shared. 372 Protected: This property MUST be protected. 374 PROPFIND behavior: This property SHOULD NOT be returned by a 375 PROPFIND allprop request (as defined in Section 14.2 of 376 [RFC4918]). 378 COPY/MOVE behavior: This property value MUST be preserved in MOVE 379 operations, but MUST NOT be preserved in COPY operations. 381 Description: This WebDAV property is present on a resource that has 382 been shared by the owner, or on the resources for the sharees. It 383 provides a list of users to whom the resource has been shared, 384 along with the "status" of the sharing invites sent to each user. 385 In addition, servers SHOULD include a DAV:principal XML element on 386 resources of the sharees to provide clients with a fast way to 387 determine who the sharer is. A server's local privacy policy may 388 prevent sharees from knowing about other sharees on a shared 389 calendar. In those cases a server may hide information about 390 other sharees. 392 4.4.3. DAV:share-resource-uri Property 394 Name: share-resource-uri 396 Namespace: DAV: 398 Purpose: A unique URI that identifies the shared resource. 400 Protected: This property MUST be protected. 402 PROPFIND behavior: This property SHOULD NOT be returned by a 403 PROPFIND allprop request (as defined in Section 14.2 of 404 [RFC4918]). 406 COPY/MOVE behavior: This property value MUST be preserved in COPY 407 and MOVE operations. 409 Description: This WebDAV property SHOULD be present on a shared 410 resource. Its content is a single DAV:href element whose value is 411 the URL of the sharer's resource being shared. The property MUST 412 contain a URI that uniquely identifies the original shared 413 resource. The URI MAY refer to a resource hosted on the same 414 server, but MAY also refer to a URN. A key requirement is that 415 this URI remains stable during the life-time of a share. 417 4.5. Handling the share process 419 This specification supports two major processes for sharing a 420 resource. The server can either immediately set up the newly shared 421 resource, or the server can provide an invitation process. The 422 former might be useful in small trusted team settings, whereas the 423 invitation process might be used in public servers, where it's 424 desirable for users to explicitly opt-in to getting access to newly 425 shared resources. 427 This specification provides a invitation and notification mechanism. 428 It might also be possible that servers provide their own out-of-band 429 mechanism for this, but this should not affect clients. 431 4.5.1. The invitation process 433 If the server opts to support the standard invitation process, the 434 server MUST support WebDAV notifications. 436 Sharees for a resource MUST appear up in the DAV:invite 437 (Section 4.4.2) property. Each sharee will have one of the following 438 elements: 440 DAV:invite-noresponse The sharee was invited, but has not yet 441 responded to the invite. 443 DAV:invite-accepted The sharee has accepted the invite. 445 DAV:invite-declined The sharee has declined the invite. 447 DAV:invite-invalid The invitation was invalid or could not be 448 delivered. 450 When sharees are initially invited, they will get the DAV:invite- 451 noresponse status. When a sharee's access has been changed, they 452 will retain their existing status. When a sharee's access has been 453 revoked, they will no longer appear in the DAV:invite property. 455 After any of these mutations, sharees receive an share-invite- 456 notification (Section 4.6.1) in their notification collection. After 457 the sharee has accepted or declined the invite, their status will 458 reflect this response. 460 4.5.2. Instant sharing 462 Implementing the invitation process is optional. It's also possible 463 for servers to immediately apply changes. The effect is that no 464 notifications may be needed, and the server behaves as if sharees 465 immediately accept invitations. Sharees listed in DAV:invite might 466 immediately receive a DAV:invite-accepted status. 468 4.6. Notification Definitions 470 In order to facilitate the process of sharing invitations, this 471 specification uses WebDAV notifications, and defines several new 472 notification types. 474 4.6.1. Invite Notification 476 When a sharer adds a new sharee to a resource, or updates a sharee, 477 an invite notification is added to the sharee's notification 478 collection. 480 The notification contains information about the shared resource, the 481 owner and how to respond to the invitation. 483 4.6.1.1. Example: An invite notification 485 This is an example of a response to a GET request on a correct reply 486 invite notification. Note that several HTTP response headers have 487 been removed for brevity. 489 HTTP/1.1 200 OK 490 Content-Type: application/davnotification+xml 491 Content-Length: xxxx 493 494 2014-08-05T13:38:02Z 495 496 497 /principals/users/evert/ 498 499 500 501 /calendars/users/evert/offdays/ 502 503 504 505 Vacation days!! 506 507 508 509 ?invite-reply 510 511 512 514 In this notification, DAV:principal indicates which principal is the 515 sharer for the resource. 517 The notification MUST contain DAV:invite-accepted or DAV:invite- 518 noresponse to indicate the current invitation status of the sharee in 519 the shared resource. New invites to shares would carry the 520 DAV:invite-noresponse status. In case the sharee had accepted an 521 earlier invite, but it's access was changed or revoked, the 522 invitation will have a DAV:invite-accepted status. 524 DAV:sharer-resource-uri refers to the DAV:sharer-resource-uri that 525 the shared resource will have, and can be used to identify which 526 invitation refers to which existing shared resource. The element MAY 527 refer to the URI of the original shared resource, but may also be a 528 urn, or any other unique URI. 530 DAV:share-access MUST be one of DAV:read-write, DAV:read or DAV:no- 531 access. This indicates that the invitee either has read-write 532 access, read-only access or no access at all respectively. 534 DAV:reply-url appears for invitations to new shared resources. The 535 url in this property can be used for a sharee to accept or decline 536 the invite. DAV:reply-url only appears for sharees with the 537 DAV:invite-noresponse status, and does not appear when DAV:share- 538 access is DAV:no-access. 540 The DAV:prop element is optional, and may contain a list of WebDAV 541 properties associated with the shared resource. Servers SHOULD at 542 least set the DAV:resourcetype, if available. This will allow a 543 client to know what kind of resource is being shared. Some clients 544 may only support responding to invites of certain kinds of resources. 545 For example, a calendaring user agent may only support CalDAV 546 calendars. 548 The DAV:comment element is also optional, and may return a brief 549 message from the sharer to the sharee. The sharer is able to specify 550 this in the original DAV:share-resource POST request. 552 4.6.2. Invite Reply 554 After a sharee has accepted or declined an invitation, the sharer 555 receives a share-reply-notification in their notification collection. 557 This notification contains information about which collection this 558 relates to, and who responded to the invite. 560 4.6.2.1. Example: An invite reply 562 This is an example of a response to a GET request on a correct invite 563 notification. Note that several HTTP response headers have been 564 removed for brevity. 566 HTTP/1.1 200 OK 567 Content-Type: application/davnotification+xml 568 Content-Length: xxxx 570 571 2014-09-03T02:30:00Z 572 573 574 mailto:john@example.org 575 576 577 /calendars/users/evert/offdays/ 578 Sorry, I'm not interested 579 580 582 In this notification, the DAV:sharee element MUST appear and contains 583 information about the updated status of the sharee in the shared 584 resource. 586 The DAV:href element MUST appear and refers to the resource the 587 sharer originally shared. 589 The DAV:comment element is optional, and may contain a message that 590 the sharee specified when responding to the invite. 592 4.7. Sharee Actions on Shared Resources 594 4.7.1. Replying to a Sharing Invite 596 When a sharee is invited to a shared resource they can accept or 597 decline the invite by issuing a POST request to the url specified in 598 the DAV:reply-url element, in the invitation notification. The POST 599 request MUST contain an XML document as its body with the root 600 element being DAV:invite-reply (Section 5.7). 602 The POST request MUST contain a Content-Type HTTP header, which MUST 603 contain "application/davsharing+xml" as its value. Servers SHOULD 604 reject the request if this is not the case. 606 The DAV:invite-reply (Section 5.7) element in the POST request 607 specifies the accept or decline action via the DAV:invite-accepted or 608 DAV:invite-declined elements, and an optional DAV:comment element. 609 IF the invite was accepted, the body MUST also contain a DAV:create- 610 in element. This element contains a single DAV:href element, which 611 content is a URI that will be used as the parent for the new shared 612 resource. 614 The client MAY also provide a DAV:slug property. The server MAY use 615 the contents of this property to determine the name of the new 616 resource. 618 All usual preconditions for creating a resource at the DAV:create-in 619 target collection need to be taken into consideration. 621 Note that some servers may restrict where certain types of resources 622 may be created. A CalDAV server for instance, may only allow 623 calendars to be created in collections identified by the 624 CALDAV:calendar-home-set WebDAV property. 626 The client MAY also provide a small comment in the DAV:comment 627 element. This comment will be sent back to the sharer. Support for 628 DAV:comment is optional. 630 A successful response to an accepted invitation, SHOULD have a HTTP 631 201 status code, and MUST have a HTTP Location header, containing the 632 full url to the newly created resource. 634 A successful response to a declined invitation, SHOULD contain a 200 635 or 204 HTTP status code. 637 When the sharee replies to an invite, the server SHOULD send a 638 notification to the sharer to update them on the change in the sharee 639 state. This is accomplished by sending a DAV:share-reply- 640 notification (Section 5.4) notification to the sharer. 642 After the sharee has issued a reply, the server SHOULD also remove 643 the notification that contained the initial invite. 645 4.7.1.1. Example: Accepting an invite 647 This is an example of a request that the sharee would send to accept 648 an invitation. 650 POST /principals/users/evert/notifications/1000455.xml HTTP/1.1 651 Host: calendar.example.com 652 Content-Type: application/davsharing+xml; charset="utf-8" 654 655 656 657 658 /calendars/users/evert/ 659 660 Tech meetups 661 Thanks for the share! 662 664 4.7.2. Ignoring an invitation 666 For privacy reasons, sharees need to be able to remove invitations 667 without notifiying the sharer. 669 When the sharee issues a DELETE on an share-invite-notification, the 670 server MUST remove the notification, and MUST NOT let the sharer know 671 about this. 673 As a result, from the sharers perspective, the invitation status for 674 that principal will always remain as DAV:invite-noreply. 676 4.7.3. Making modifications to a shared resource 678 Any changes that a sharee makes to a shared resource should also be 679 reflected in the sharers instance of the resource. 681 If the shared resource is a collection, any resources in the 682 collection, or in the collection's child-collections MUST also appear 683 in the sharers instance. 685 4.7.4. Removing a shared resource 687 To remove a shared resource a DELETE request is targeted at the 688 shared resource URI. When such a request is received the server MUST 689 remove the shared collection and automatically update the sharee's 690 status in the sharer's DAV:invite (Section 4.4.2) property. 692 4.8. General Considerations 694 4.8.1. Per-instance WebDAV Properties 696 Servers MUST support "per-instance" WebDAV properties on shared 697 resource and MAY support them on resources within shared collections. 698 A "per-instance" WebDAV property is one whose value can be set and 699 retrieved on an instance of a resource, but is not automatically 700 propagated to other instances of the same shared resource. For 701 example, a sharee may change a property on their instance of a shared 702 resource, but the instance of the owner of the resource will not see 703 this updated value. 705 For shared resources, the server MUST allow all users to write "per- 706 instance" WebDAV properties on the shared resources and MAY allow 707 property writes on resources within the shared resources. This is 708 required even in the case where the sharee has been granted read 709 access only (i.e., the ability to change the resource is disallowed). 710 This requirement ensures that sharees can always change "personal" 711 properties such as display names. 713 Servers MAY treat any dead property as per-instance. 715 Servers MUST NOT treat live properties as per-instance. 717 4.8.2. Sharees and instances 719 A point that may not be immediately obvious, is that there is a 720 separation between sharees and shared instances. 722 Sharees (and sharers) are effectively only 'actors' in the sharing 723 process and allow shared instances to be created and modified. The 724 sharing "role" or access level that a user has when performing an 725 opteration on a shared resource, is dependent on which intance they 726 are accessing, not who the currently logged in principal is. 728 To illustrate, take the DAV:share-access WebDAV property. This 729 property should always describe the access-level of the instance, not 730 the current user accessing the property. 732 An implication is that if an owner of a shared resource also has 733 direct access to a shared instance of a sharee (via normal WebDAV ACL 734 controls for example), requesting the share-access property on that 735 shared resource should always indicate DAV:read or DAV:read-write, 736 but never DAV:shared-owner. 738 Likewise, if a sharee also has direct access to the original shared 739 (owner) instance on the same server, the DAV:share-access property 740 should always return DAV:shared-owner. 742 This philosophy must be considered when designing the underlying 743 data-model of the server, and every feature in this specification. 744 That is: the sharing-role a user has when accessing a shared- 745 resource, is generally dependent on the resource being accessed, not 746 the current principal. 748 4.8.3. Relationship between sharing access levels and WebDAV ACL 750 This document describes a way for a user to grant access to other 751 resources, sidestepping WebDAV ACL [RFC3744]. 753 WebDAV ACL is still relevant though. The DAV:share ACL privilege is 754 used to indicate that a user is allowed to share a resource. 756 This specification uses the DAV:read and DAV:read-write access levels 757 to indicate the access level of the shared resource. 759 These privileges don't directly correlate to ACL privileges. It's 760 left up to the implementor to decide which ACL privileges are the 761 most appropriate for both DAV:read and DAV:read-write. 763 The following is a suggestion: Sharees with a DAV:read share-access 764 level, may typically at least expect DAV:read, DAV:write-properties, 765 DAV:read-current-user-privilege set. 767 For DAV:read-write, this also includes DAV:write, DAV:write-content, 768 and if the shared resource is a collection, DAV:bind and DAV:unbind. 770 These privileges are typically applied to the shared resource and all 771 its child resources (if any). 773 There is no requirement for the shared instance to have a DAV:owner 774 element that refers to the original sharer. In fact, it SHOULD 775 probably be the sharee. Likewise, there is also no requirement for 776 the original sharer to have any privileges to any of the sharee 777 instances. 779 5. XML Element Definitions 781 The following section contains a definition of all the XML elements 782 used in this document The definitions are written in the form of a 783 DTD. The DTD itself non-normative and for reference only. 785 It should be noted that several elements in the following sections 786 are repeated, sometimes with varying definitions. This is because 787 some of these elements have slightly different definitions depending 788 on the context in which they appear in. 790 5.1. DAV:share-resource 792 The following section describes the DAV:share-resource element, which 793 is defined in Section 4.3 795 797 798 800 801 803 804 806 807 809 810 812 813 815 819 820 5.2. DAV:share 822 The share element is a WebDAV ACL [RFC3744] privilege that allows a 823 client to inspect whether a user may be allowed to share a resource. 824 The element is defined in Section 4.2. 826 828 5.3. DAV:share-invite-notification 830 DAV:share-invite-notification is used within a WebDAV notification to 831 communicate to a sharee that a sharer is sharing a resource, or 832 changing the access level to a resource. DAV-share-invite- 833 notification is defined in Section 4.6.1 835 836 838 839 842 843 845 846 848 849 851 852 854 855 857 858 860 861 863 864 866 867 869 870 872 873 874 876 5.4. DAV:share-reply-notification 878 DAV:share-reply-notification is a notification that appears in a 879 sharers notification collection when a sharee responded to an 880 invitation. It is defined in Section 4.6.2 881 882 884 885 889 890 892 893 895 896 898 899 901 5.5. DAV:invite 903 DAV:invite is a live WebDAV property, defined in Section 4.4.2. This 904 property allows a sharer or sharee to inspect who has access to a 905 particular resource, their invitation status and access level. 907 908 910 911 916 917 919 920 922 923 925 926 928 929 931 932 934 935 937 938 940 941 943 944 946 5.6. DAV:share-access 948 DAV:invite is a live WebDAV property, defined in Section 4.4.1. This 949 property allows sharer or sharee to inspect the sharing status of the 950 resource. 952 953 955 956 958 959 961 962 964 965 967 5.7. DAV:invite-reply 969 DAV:invite-reply is the root element of a POST request that a sharee 970 would issue to respond to an invitation. It is defined in 971 Section 4.7.1. 973 976 977 979 980 982 984 985 987 988 990 991 993 6. Security Considerations 995 6.1. Forced shares 997 When this specification is implemented without the use of the 998 notification flow, as described in Section 4.5.2, it may be possible 999 that a malicious user can create unwanted resources for a target 1000 user. 1002 If this is a concern, taking advantage of the notification process is 1003 highly recommended. 1005 6.2. Notification spamming 1007 If a server does deploy the entire notification process, a user with 1008 malicious intent may still generate a large amount of notifications 1009 targetting other users. 1011 Servers SHOULD at the very least ensure that multiple share 1012 invitations for the same resource are coalesced into a single 1013 invitation. 1015 7. IANA Considerations 1017 This document defines a MIME media type for XML documents used in for 1018 sharing. This media type SHOULD be used for all POST requests in 1019 this specification. 1021 Type name: application 1023 Subtype name: davsharing+xml 1025 Required parameters: none 1027 Optional parameters: none 1029 Encoding considerations: Identical to those of "application/xml" as 1030 described in RFC7303 [RFC7303]. 1032 Security considerations: N/A. 1034 Interoperability considerations: There are no known interoperability 1035 issues. 1037 Published specification: This specification. 1039 Applications that use this media type: No known applications 1040 currently use this media type. 1042 Fragment identifier considerations: N/A. 1044 Additional information 1046 Deprecated alias names for this type N/A. 1048 Magic number(s) N/A. 1050 File extension(s) xml 1052 Macintosh file type code(s) TEXT 1054 Person & email address to contact for further information: 1055 me@evertpot.com 1057 Intended usage COMMON 1059 Restrictions on usage There are no restrictions on where this media 1061 Author See the "Authors' Addresses" section of this document. 1063 Change Controller IETF 1065 8. Acknowledgments 1067 The authors would like to thank the members of the Calendaring and 1068 Scheduling Consortium's SharingTechnical Committee. In particular, 1069 the following individuals have made important contributions to this 1070 work: Richard Brigham, John Chaffee, Michael Douglass and Ken 1071 Murchison and Dave Thewlis. 1073 This specification originated from work at the Calendaring and 1074 Scheduling Consortium, which has supported the development and 1075 testing of implementations of the specification. 1077 9. Normative References 1079 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1080 Requirement Levels", BCP 14, RFC 2119, 1081 DOI 10.17487/RFC2119, March 1997, 1082 . 1084 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1085 Distributed Authoring and Versioning (WebDAV) Access 1086 Control Protocol", RFC 3744, DOI 10.17487/RFC3744, May 1087 2004, . 1089 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 1090 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 1091 DOI 10.17487/RFC4791, March 2007, 1092 . 1094 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 1095 Authoring and Versioning (WebDAV)", RFC 4918, 1096 DOI 10.17487/RFC4918, June 2007, 1097 . 1099 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed 1100 Authoring and Versioning (WebDAV)", RFC 6352, 1101 DOI 10.17487/RFC6352, August 2011, 1102 . 1104 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1105 DOI 10.17487/RFC7303, July 2014, 1106 . 1108 Appendix A. Backwards compatibility 1110 This specification is based on an earlier effort, often referred to 1111 as 'caldav-sharing'. It is possible to remain compatibile with this 1112 specification, but it's important to be aware of a number of changes. 1114 The earlier draft uses the http://calendarserver.org/ns/ namespace 1115 for all its xml elements. This means that any WebDAV property 1116 introduced in this specification, may need to have a similar property 1117 in the old namespace. 1119 XML documents as sent by POST requests and responses, and resources 1120 returned from notifications can be distinguished by the use of the 1121 Content-Type and Accept HTTP headers. The earlier draft does not 1122 define new mime-types for these, but this specification does. 1124 Appendix B. Change History (to be removed prior to publication as an 1125 RFC 1127 Changes in -04: 1129 1. Corrected the application/davsharing+xml mimetype where it was 1130 misspelled. 1132 2. Lots of small spelling/english fixes. 1134 3. Changed sharer-resource-uri into share-resource-uri. This new 1135 uri makes a bit more sense. 1137 Changes in -03: 1139 1. A major rewrite, making many xml elements self-consistent and 1140 with other WebDAV specifications. 1142 2. While all of the same data is still there, many xml elements 1143 have changed. 1145 3. Added 'Instant sharing' concept, making notifications 1146 integration optional. 1148 4. Removed DAV:share-mode 1150 5. Added DAV:share-access 1152 6. Added a DAV:sharee element with a consistent set of information 1153 about sharees. 1155 7. Clarified the nature of DAV:invite-accepted element in 1156 DAV:invite-notifaction documents. 1158 8. Introduced the DAV:reply-url element. 1160 9. DAV:sharer-instance-url is now DAV:sharer-instance-uri and may 1161 contain other uris. 1163 10. Added security concerns. 1165 11. Complete rewrite of the XML Elements section, using DTDs. 1167 12. DAV:invite-notification is now DAV:share-invite-notification. 1169 13. DAV:reply-notification is now DAV:share-reply-notification. 1171 14. Added design philosophy section. 1173 15. Added information about relationship with WebDAV ACL. 1175 Changes in -02: 1177 1. Renamed DAV:shared-url to DAV:sharer-instance-url. 1179 2. Introduced DAV:share-mode WebDAV property. 1181 3. Removed additions to DAV:resource-type to indicate that a 1182 resource is shared. 1184 Changes in -01: 1186 1. Fixed some issues in the DTD declatations of set-invitee and 1187 remove-invitee. 1189 2. Removed an unused normative reference. 1191 3. Removed 'open issues' section. 1193 4. Added a paragraph about xml/dtd handling with a reference to 1194 RFC4917 1196 5. Renamed DAV:share to DAV:share-resource for the POST request 1198 Authors' Addresses 1200 Evert Pot 1201 fruux GmbH 1202 Koenigsstrasse 32 1203 Muenster, NRW 48143 1204 Germany 1206 Email: me@evertpot.com 1207 URI: https://fruux.com/ 1209 Cyrus Daboo 1210 Apple Inc. 1211 1 Infinite Loop 1212 Cupertino, CA 95014 1213 USA 1215 Email: cyrus@daboo.name 1216 URI: http://www.apple.com/ 1218 Eric York 1219 Apple Inc. 1220 1 Infinite Loop 1221 Cupertino, CA 95014 1222 USA 1224 URI: http://www.apple.com/